I still feel like it could be a problem to have just one simple
getPageSize method, given how many CPU architectures and OSes support
multiple page sizes.
On 11/04/2016 11:58 AM, Paul Sandoz wrote:
Hi Lucy,
I am struggling to find an entirely satisfactory location to place a method
such as g
Hi Paul,
Thank you very much for all your suggestions.
Currently, we add getAlignment() function to FileChannel and override it in
FileChannelImpl with details. Basically, it just calls
sun.nio.ch.Util.pageSize().
However, if you think exposing pageSize() from java.lang.Runtime is a better
Hi Lucy,
I am struggling to find an entirely satisfactory location to place a method
such as getPageSize, but java.lang.Runtime seems less worse than other places
:-)
Paul.
> On 3 Nov 2016, at 12:49, Lu, Yingqi wrote:
>
> Hi Paul and Peter,
>
> Thank you very much for pointing this out. We
Why not call aligned_alloc for doing page alignment? It should waste much
less memory.
http://en.cppreference.com/w/c/memory/aligned_alloc
On Thu, Nov 3, 2016 at 8:14 AM, David M. Lloyd
wrote:
> What happens if you're using large pages? Are the direct buffers always
> allocated off of small p
On 04/11/2016 02:08, Stuart Marks wrote:
Hi all,
Please review this small set of changes to the immutable collections
to make the zero-size instances singletons. (JDK-8156079)
This also includes a couple other small optimizations (JDK-8169222) to
change the expansion factor from floating po
On 04/11/2016 00:52, Mandy Chung wrote:
Looks fine overall. I think it’s useful to add a section header “Multi-Release
JAR File” in JarFile class specification that URLClassLoader can link to
directly when referring “multi-release JAR file” and other specs can make use
of too.
The javadoc
On 11/4/16 12:08 AM, Remi Forax wrote:
the static methods in ImmutableCollections do not need to be final there are
already static.
Oh yes, good point. I'll fix it. Thanks.
s'marks
+1
/Claes
On 2016-11-04 03:08, Stuart Marks wrote:
Hi all,
Please review this small set of changes to the immutable collections
to make the zero-size instances singletons. (JDK-8156079)
This also includes a couple other small optimizations (JDK-8169222) to
change the expansion factor from
Thank you Roger and Daniel for reviewing.
I'll push webrev.02 with the fix for line 54 typo :-)
Thanks,
Amy
On 11/4/16 9:51 PM, Roger Riggs wrote:
Hi Amy,
yes, this looks fine; no need for the RMI Registry in the test.
Perhaps you can fix the typo: line 54: "Exdecute" =-> "Execute";
no nee
Hi Amy,
yes, this looks fine; no need for the RMI Registry in the test.
Perhaps you can fix the typo: line 54: "Exdecute" =-> "Execute";
no need for another webrev.
Thanks, Roger
On 11/4/2016 9:33 AM, Daniel Fuchs wrote:
Hi Amy,
Looks good to me.
Might be good to have confirmation from R
Hi Amy,
Looks good to me.
Might be good to have confirmation from Roger or Stuart
that no longer using the registry is OK WRT to the
purpose of this test. If so then this looks like
the ideal solution :-)
best regards,
-- daniel
On 04/11/16 13:27, Amy Lu wrote:
Hi, Daniel
I updated webrev,
Hi, Daniel
I updated webrev, removed the test dependency on TestLibrary.
(RMI logging still be triggered thus no change to testing purpose.)
Please review again:
http://cr.openjdk.java.net/~amlu/8037278/webrev.02/
Thanks,
Amy
On 11/3/16 9:42 PM, Daniel Fuchs wrote:
On 03/11/16 13:35, Daniel F
Looks good,
the static methods in ImmutableCollections do not need to be final there are
already static.
Rémi
On November 4, 2016 3:08:58 AM GMT+01:00, Stuart Marks
wrote:
>Hi all,
>
>Please review this small set of changes to the immutable collections to
>make the
>zero-size instances singl
13 matches
Mail list logo
