On Wed, 1 Jun 2022 10:37:23 GMT, Raffaello Giulietti
wrote:
>> Hello,
>>
>> here's a PR for a patch submitted on March 2020
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was
>> a thing.
>>
>> The patch has been edited to adhere to OpenJDK code conventions about
avalry, to sanction their incoherent
proposals.
Best not to feed someone like this; trolls are greedy beasts and grow to
disproportionate size the more you feed them.
regards,
Andrew Dinn
---
On Fri, 17 Sep 2021 07:13:24 GMT, Wu Yan wrote:
>> It's fine. I don't think it'll affect any real programs, so it's rather
>> pointless. I don't know if that's any reason not to approve it.
>
> Andrew, can you help us to approve this?
I agree with Andrew Haley that this patch is not going to ma
to be significant given Andrew's micro-benchmark results.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
On Fri, 2 Jul 2021 09:39:46 GMT, Andrew Haley wrote:
>> src/java.base/share/classes/java/lang/Math.java line 1211:
>>
>>> 1209: long z1 = t >>> 32;
>>> 1210:
>>> 1211: return x1 * y1 + z1 + (z0 >>> 32);
>>
>> Suggestion:
>>
>> long result = Math.multiplyHigh(x, y);
>>
On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang wrote:
> Prefer using ByteOrder to compute byte order for StringUTF16 to determining
> byte order by native method StringUTF16.isBigEndian.
Hi Yi Yang,
This is more complex than it seems. The general policy is not to change boot
order if at all possib
On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne
wrote:
> Glibc 2.29 onwards provides optimised versions of log,log10,exp.
> These functions have an accuracy of 0.9ulp or better in glibc
> 2.29.
>
> Therefore this patch adds code to parse, store and check
> the runtime glibcs version in os_linux
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter
wrote:
>> To allow agents the definition of auxiliary classes, an API is needed to
>> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or
>> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed
t;pow(-0.F, 0.5) = %f\n", pow(-0.F, 0.5));
}
END
$ make sqrt
cc sqrt.c -o sqrt
$ ./sqrt
sqrt(-0.F) = -0.00
pow(-0.F, 0.5) = 0.00
I have no idea why these specific results were made up for C but Java
really ought to follow them.
regards,
Andrew Dinn
---
Red Hat Dis
will make any difference to performance I think it is
better to keep this code as is.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
On Tue, 22 Sep 2020 02:31:14 GMT, Vladimir Kozlov wrote:
>>> >Can you explain where this restricted effect is documented?
>>
>>> Certainly! I’ve found that determining the capability of the CPU and
>>> whether to enable AVX2 support if the chip
>>> supports it is mostly controlled in: vm_v
On Fri, 18 Sep 2020 23:11:46 GMT, Jason Tatton
wrote:
> >Can you explain where this restricted effect is documented?
> Certainly! I’ve found that determining the capability of the CPU and whether
> to enable AVX2 support if the chip
> supports it is mostly controlled in: vm_version_x86.cp
On Fri, 18 Sep 2020 15:55:52 GMT, Jason Tatton
wrote:
>> Hi Andrew,
>>
>> Thanks for coming back to me. Looking on the github
>> [PR](https://github.com/openjdk/jdk/pull/71) nobody is tagged as a
>> reviewer for this (perhaps this is a feature which is not being used).
>>> That's
>>> because w
be a good idea to consider finding some way to test whether the
cost Andrew has highlighted makes a difference before committing this
change. I know the same argument might might be raised aginst the
existing intrinsics but surely that's an a fortiori argument for not
proceeding.
regards,
An
elected the above response.
What you did not get was license to proceed and push this change. That's
because what is actually missing is the justification he asked for. As
Andrew pointed out the change is simple but the reason for implementing
it is not.
regards,
Andrew Dinn
---
Red Hat
vectorized. In that case the
loading of the int contents would need to be ordered wrt the load of the
int[] references using a LoadLoad barrier?
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Di
584/latest
The relevant text is in section 4.4. Memory Ordering.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
function. Is there
any expectation/requirement that it could/should do something more than
that?
I am also wondering if this is the only such omission or if other libs
might require a corresponding JNI_OnLoad_extnet_xxx function.
regards,
Andrew Dinn
---
> On 12/05/2020 19:46, Bob Van
ve here. I
have posted this reply because it's critically important that we, the
OpenJDK project devs, understand and keep in mind how most app
developers use (are able to use) Java. Suggestions that bypass the
realities and limitations of that usage say to me that we are at risk of
not meet
On 24/03/2020 09:10, Magnus Ihse Bursie wrote:
> On 2020-03-24 09:59, Andrew Dinn wrote:
>> I'm assuming that also implies it is trivial (because, copyright update
>> a side, it really is a 1-liner :-).
>
> For code in the build system, we do not have the Hotspot rul
On 23/03/2020 18:38, Erik Joelsson wrote:
> Looks good.
Thanks for the review, Erik.
I'm assuming that also implies it is trivial (because, copyright update
a side, it really is a 1-liner :-).
I will push to the dev tree and request a backport to jdk14u.
regards,
And
.
JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144
webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev
Testing:
Built image and compiled + ran Hello World.
Built make target docs-jdk-api-javadoc and checked module
jdk.nio.mapmode was included in output
regards,
Andrew Dinn
t of the JNI entrypoints in the shared library using a
linker map. Indeed, OpenJDK does this to limit visibility of entrypoints
to libjvm.
Is there a reason why this is not a viable alternative to changing the
definition of the JNIEXPORT macros?
regards,
Andrew Dinn
---
e
Graal project that needs to watch out.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
ed byte buffers and all is well.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
ashes the VM.
>
> Perhaps this could be reworked to remove the bool cleanly, but let's go
> back to open.01 and move that cleanup to a follow-up.
Sure, no problem.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company
On 22/10/2019 12:05, Claes Redestad wrote:
> On 2019-10-22 12:44, Andrew Dinn wrote:
>> Why not leave it void?
>
> I guess:
>
> http://cr.openjdk.java.net/~redestad/8232613/open.02/
Ship it ;-)
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat
version).
Why not leave it void?
regards,
Andrew Dinn
---
#x27;well known class init' code.
regards,
Andrew Dinn
---
On 19/08/2019 15:36, Alan Bateman wrote:
> I think webrev.12 looks good; I don't have any other comments.
Thanks, Alan. I just pushed the patch for the JEP implementation.
(Hallelujah!). Thanks for all your help.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Ha
/do/ need to fix the typo in the test where is says
"expected true of false as an argument"
Obviously that should say "true *or* false".
regards,
Andrew Dinn
---
(I have no access to the
necessary kit).
Red Hat MW tests:
All still passing successfully
submit test:
still in progress
Is it ok to push if the submit test comes back clean?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales
such gives us useful information like this:
I have already done this too :-)
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
important thing is that we should get either
IOException or UnsupportedOperationException. Checking for the message
is not really necessary. I will remove this check from the test.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under
lan Bateman will be happy to consider your proposal. Indeed, I would be
happy to implement it given his approval -- or leave it to you to do so
if you prefer.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registr
d
in the main comment. So, the scenario you describe is not really an
intended usage and I woudl argue that a failure is the right way to
signal that.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
p://cr.openjdk.java.net/~adinn/8224974/webrev.11
>
> Looks good.
Ok, I'll fold this and the other format errors you identified into the
next patch.
If I could please get a nod from Alan Bateman (and assuming I don't
receive further comments from other reviewers) I'll pus
Hi Aleksey/Boris,
This is a response to both your last review posts. New webrev link is at
the end.
On 01/08/2019 12:16, Aleksey Shipilev wrote:
> On 7/31/19 12:55 PM, Andrew Dinn wrote:
. . .
> I am more concerned that the writeback call enters the pre sync stub
> unnecessarily.
Th
to ensure that writeback is
never attempted on x86_32.
Thank you for spotting these errors. I will add the relevant fixes to
the next patch and add you as a reviewer.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under
h a test
to the next webrev.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 31/07/2019 16:46, Aleksey Shipilev wrote:
> On 7/31/19 4:46 PM, Andrew Dinn wrote:
>> Well, the failure happened during the build process so I didn't
>> (couldn't) debug it. I disabled the assert in supports_cpuflush() in
>> order to allow the build to complete an
On 31/07/2019 12:40, Aleksey Shipilev wrote:
> On 7/31/19 1:29 PM, Andrew Dinn wrote:
>> I have an update regarding the change to the computation of the
>> CPU_FLUSH flag. After posting the new webrev I built a debug version
>> with the change that tests the clflush bit on x8
et to the submit repo and it came back with no errors:
> Job: mach5-one-adinn-JDK-8224974-8-20190730-1325-4068436
> BuildId: 2019-07-30-1324012.adinn.source
> No failed tests
. . .
Is x86_32 tested as part of a submit run?
regards,
Andrew Dinn
---
Senior Principal Software Eng
I
am able to execute clflush quite happily.
"Toto, it looks like we are no longer in Antarctica."
So, I will revert this change (in the next webrev).
regards,
Andrew Dinn
---
On 31/07/2019 11:55, Andrew Dinn wrote:
> Hi Aleksey
>
> On 30/07/2019 17:00, Aleksey Shi
Hi Aleksey
On 30/07/2019 17:00, Aleksey Shipilev wrote:
> On 7/30/19 5:04 PM, Andrew Dinn wrote:
>> JEP 352 has now been targeted for inclusion in JDK14. The latest webrev
>> for the implementation JIRA has been rebased to apply to the current
>> tree. Is it now ok to
/webrev.09
n.b. by way of sanity test I pushed this to the submit repo and it came
back with no failed tests.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham
Hi Alan,
On 02/07/2019 16:59, Alan Bateman wrote:
> On 18/06/2019 12:43, Andrew Dinn wrote:
> One nit is that the update to the Goals section says "rework" in two
> places. I think it might more accurate to say "upgrade" or "update" as
> it doe
and targeting of the JEP.
regards,
Andrew Dinn
---
On 18/06/2019 12:43, Andrew Dinn wrote:
> Hi Alan,
>
> Thanks for reviewing the JEP one more time.
>
> On 16/06/2019 09:47, Alan Bateman wrote:
>> I re-read the JEP, trying to put myself in the position of someone
ll also
include the changes pending after Joe's review of the implementation CSR
leaving (I hope) only my recently proposed JEP updates and endorsement
to finish before it can be pushed.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England an
Hi Alan,
On 19/06/2019 14:11, Alan Bateman wrote:
> On 19/06/2019 11:07, Andrew Dinn wrote:
>> :
>> Do I still need to wait for confirmation for the CSR from Joe Darcy
>> before pushing to the jdk13 repo? (He already knows about the CSR).
>>
> Yes, anything that ha
about the CSR).
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
ava.net/browse/JDK-8226385
and tagged it for jdk13.
Also, I labelled it SE -- but is it, perhaps, meant to be JDK?
(apologies, I am still a noob to this process).
Bug:https://bugs.openjdk.java.net/browse/JDK-8226203
Webrev: http://cr.openjdk.java.net/~adinn/8226203/webrev.00/
regards,
is a problem then I am happy for it to go
into jdk14.
regards,
Andrew Dinn
---
03 [1] to track it. As support for
> implementation specific map modes is in new in Java SE 13 then it might
> be worth trying to get that fixed now while it is fresh in our minds.
Sure, I'll post an RFR with the javadoc patch as a separate step. Can it
go into jdk13? or is it too lat
On 10/06/2019 18:44, Alan Bateman wrote:
> On 10/06/2019 11:09, Andrew Dinn wrote:
>> :
>> Finally, I am unclear whether the presence of the new module + package
>> means this is an SE JEP or a JDK JEP? In the latest update I have
>> assumed the JEP type is still JDK an
webrev once I am sure there
are no other changes needed.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
t;Proposed Java API Changes". Is that right? Or do you
want the JEP type to be SE and have the title remain "Proposed Java SE
API Changes"
regards,
Andrew Dinn
---
On 09/06/2019 16:53, Alan Bateman wrote:
> On 07/06/2019 12:24, Andrew Dinn wrote:
>> :
>> Modulo confirmation of those two checks this looks like it is a complete
>> implementation. Unless anyone has more changes to recommend?
>>
> I read through the recent mails a
On 07/06/2019 12:24, Andrew Dinn wrote:
> On 06/06/2019 18:40, Vladimir Kozlov wrote:
>> Hotspot changes looks good.
>>
>> CheckGraalIntrinsics failed because of typo - you should use 'J' instead
>> of 'L':
>>
>> + "jdk/
uilds pass. I have also asked Jonathan Halliday to re-test this version
against the Red Hat middleware clients to ensure there are no functional
or performance changes.
Modulo confirmation of those two checks this looks like it is a complete
implementation. Unless anyone has more changes to recommend
(set-variable 'show-trailing-whitespace t)
> )))
There, fixed that for ya!
> ...and you'll never have any trouble with trailing whitespace again.
Now working beautifully, thank you!
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Regist
Hi Gustavo,
On 05/06/2019 19:13, Gustavo Romero wrote:
> I found some trailing space in v5 and it seems they are in v6 as well.
Thanks for the heads up. I will fix these in the next webrev (07).
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered
o happen? Or perhaps the test is
supposed to be added to the problem or exclude lists?
> Sorry for suggesting the change that was the proximate cause of this. :-(
No problem :-) Thanks for reviewing and checking!
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat
MAP_MODE_CONSTRUCTOR.
> 13:Insert blank line after
> 34-36:Move to before line 13.
> 24:Move constructor to end of class.
Yes, all good. Thanks!
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 04/06/2019 11:40, Alan Bateman wrote:
> On 03/06/2019 15:37, Andrew Dinn wrote:
>> :
>>
>> The CSR and JEP have been updated accordingly
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8224975
>> JEP: https://bugs.openjdk.java.net/browse/JDK-820785
On 03/06/2019 14:17, Andrew Dinn wrote:
> Hi Vladimir,
>
> Thanks for the follow-up and for checking the submit failure. I have
> addressed all the points you raised (point by point comments are
> included below). A new webrev which passes a submit run is he
includes changes to the javadoc for
ExtendedMapMode suggested by Alan Bateman.
regards,
Andrew Dinn
---
On 30/05/2019 17:58, Vladimir Kozlov wrote:
> On 5/30/19 9:08 AM, Andrew Dinn wrote:
>> I have uploaded a new webrev which attempts to address the problem.
>
iewed with at least provisional
agreement before that can happen. Also, the JEP still needs endorsing by
at least one relevant Group or Area Lead (I think that probably means
Alan, Brian or Vladimir).
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in En
for new intrinsics (add them to
> 'toBeInvestigated' for isJDK13orHigher):
>
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
That has been fixed in the webrev mentioned above.
regards,
Andrew Dinn
net/~adinn/8224974/webrev.02/
n.b. I have switched to using the subtask JIRA id in $title and in the
cr.openjdk webrev link ...
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Director
Hi Alan,
I have created a new JEP implementation JIRA (note change to thread
title) and associated draft CSR
Impl JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974
CSR JIRA:
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and
d if run with a test JDK that
> doesn't have this module.
Yes, I agree that @run main/manual is far better than @ignore and the
@modules requirement is also a very good idea. I have updated both.
New webrev: http://cr.openjdk.java.net/~adinn/8207851/webrev.01
regards,
Andrew Dinn
--
Ping!
Any takers for a review?
Also, can anyone advise me on what I might need to do to target this JEP
to JDK13, other than the obvious reviewing and pushing of the
implementation?
regards,
Andrew Dinn
---
On 23/05/2019 11:55, Andrew Dinn wrote:
> Hi,
>
> Could I pl
critical since there is currently no general access to the
relevant hardware.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 16/05/2019 17:27, Alan Bateman wrote:
> On 16/05/2019 15:49, Andrew Dinn wrote:
>> Please review this trivial change to MapperByteBuffer which encapsulates
>> the page align down operation in a suitably named method.
>>
>> JIRA: https://bugs.openjdk.java.net/browse/
On 16/05/2019 17:24, Mikael Vidstedt wrote:
>
> Looks good, thanks for doing it!
Thanks for the review Mikael.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: M
Hi Thomas,
Thanks for the review.
On 16/05/2019 16:54, Thomas Stüfe wrote:
> looks good and trivial. Method could be static.
Yes, good point! I will modify accordingly and then push.
regards,
Andrew Dinn
---
.
Indeed. I have raised JDK-8224042, patched and tested the code, uploaded
a webrev and posted an RFR (T) to core-libs-dev. Reviews welcome!
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Di
running
jdk/java/nio/channels/FileChannel/MapTest.java
The test rounds down a sequence of sub-page offsets to successive pages
within a mapped buffer during testing of MappedByteBuffer method force().
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered
On 14/05/2019 10:57, Andrew Haley wrote:
> On 5/13/19 5:14 PM, Andrew Dinn wrote:
>> Thank you for looking at the patch.
>> . . .
>>firstly, that ps-1 clears the original bit and sets all lower bits;
>
> I think your core argument fails at this point. You have *alre
JEP
implementation?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 26/04/2019 15:46, Alan Bateman wrote:
On 25/04/2019 17:34, Andrew Dinn wrote:
Also, here is a new webrev including the updated implementations for
mappingAddress/Offset/Length as described below
JIRA: https://bugs.openjdk.java.net/browse/JDK-8221696
webrev: http://cr.openjdk.java.net
Thank you for looking at the patch.
On 28/04/2019 18:09, Andrew Haley wrote:
On 4/25/19 5:34 PM, Andrew Dinn wrote:
long map_base = (address & ~(ps - 1));
This looks like a hard way to write
long map_base = address & -ps;
My version certainly uses more characters, that is
Also, here is a new webrev including the updated implementations for
mappingAddress/Offset/Length as described below
JIRA: https://bugs.openjdk.java.net/browse/JDK-8221696
webrev: http://cr.openjdk.java.net/~adinn/8221696/webrev.02
regards,
Andrew Dinn
---
On 23/04/2019 17:15, Andrew
ct? If so I will prepare a new webrev accordingly.
> I don't expect any issues on Windows but I will test it to make sure.
Thank you. That would be very helpful.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Re
Hi Alan,
The CSR for this issue has been finalized and is awaiting approval.
Would it now be possible to proceed with reviews of the implementation?
JIRA: https://bugs.openjdk.java.net/browse/JDK-8221696
webrev: http://cr.openjdk.java.net/~adinn/8221696/webrev.01
regards,
Andrew Dinn
---
On 11/04/2019 11:34, Alan Bateman wrote:
> On 10/04/2019 12:15, Andrew Dinn wrote:
>> :
>> An updated webrev is available:
>>
>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8221696
>> webrev: http://cr.openjdk.java.net/~adinn/8221696/webrev.01
>>
>&
Could I please get a review for the following CSR which accompanies
JDK-8221696
JIRA: https://bugs.openjdk.java.net/browse/JDK-861
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
e/JDK-8221696
webrev: http://cr.openjdk.java.net/~adinn/8221696/webrev.01
I will also create a CSR based on the changes in this webrev and post an
RFR.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
will have to
record and translate buffer coordinates. I would prefer this requirement
to be fully present or fully removed rather than imposing it for one
case but not the other.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wal
On 09/04/2019 19:30, Andrew Haley wrote:
> On 4/9/19 11:42 AM, Andrew Dinn wrote:
>> This new API method was conceived as a preliminary change for JEP 352 to
>> allow selective writeback of NVRAM-backed buffers. However, it has been
>> implemented to provide a similar capab
On 09/04/2019 17:49, Alan Bateman wrote:
> On 09/04/2019 17:02, Andrew Dinn wrote:
>> In response to Alan's suggestion (included below) I have reverted the
>> constructor for MapMode to private and will use behind the scenes access
>> to construct the extended enum
net/~adinn/8221397/webrev.03
Testing:
Submit repo: in progress
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shan
On 09/04/2019 10:09, Andrew Dinn wrote:
> Could I please get a review for the following CSR. It relates to the
> change proposed in JDK-8221397 which enables FileChannel
> implementation-specific extensions to enum MapMode.
>
> https://bugs.openjdk.java.net/browse/JDK-8222107
On 09/04/2019 16:04, Daniel Fuchs wrote:
> . . .
> That reads fine, thanks!
Good. Thanks for reviewing this.
> BTW: I haven't really looked at the implementation, I'm leaving that to
> the experts of the field :-)
No problem. I await their expert judgement.
On 09/04/2019 13:21, Claes Redestad wrote:
> On 2019-04-09 11:05, Andrew Dinn wrote:
>> It would probably also be good if you extended the comment to document
>> the status quo i.e. as Peter noted that the assigned values are computed
>> deterministically from immutable state
On 09/04/2019 13:47, Alan Bateman wrote:
> On 08/04/2019 15:05, Andrew Dinn wrote:
>> :
>> Hmm, yes that's an interesting point. Of course, I'll take whatever
>> suggestions you are willing to throw this way :-)
>>
> What would you think about not
Hi Daniel,
Thanks for looking at this.
On 09/04/2019 12:28, Daniel Fuchs wrote:
> Hi Andrew,
>
> On 09/04/2019 11:42, Andrew Dinn wrote:
>> One detail that is worth highlighting is that for file-backed buffers
>> the start address passed to the native method force0 is roun
test TEST=test/jdk/java/nio/channels/FileChannel/MapTest.java"
]
Updated MapTest.java: passes on Linux
Submit Test: in progress
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Dire
Could I please get a review for the following CSR. It relates to the
change proposed in JDK-8221397 which enables FileChannel
implementation-specific extensions to enum MapMode.
https://bugs.openjdk.java.net/browse/JDK-8222107
Thanks.
regards,
Andrew Dinn
---
Senior Principal
1 - 100 of 195 matches
Mail list logo
