On 02/05/2014 11:21 AM, Alan Bateman wrote:
On 05/02/2014 08:08, Peter Levart wrote:
Hi,
I'm proposing a patch for the following issue:
https://bugs.openjdk.java.net/browse/JDK-6857566
The patch is basically the same as developed and tested as part of
the following discussion 3 months ago:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021547.html
It's just modified to be applied on top of JDK9 which already changed
since then. Here's the webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferAlloc/webrev.01/
Hi Alan,
I made another webrev with minor changes based on your feedback...
http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferAlloc/webrev.03/
Thanks for re-basing the changes and from the previous discussion then
I think there was agreement on the approach. So I'd say this is ready
to go into jdk9/dev.
A minor comments on the usages of tryHandlePendingReferences in Bits
that it might be a bit neater to not split the line. At least when
looking at the patch then it makes it a bit more obvious what is
condition vs. statement in the while loop.
I did that by extracting the reference to JavaLangRefAccess into a local
variable.
Another minor comment is that usually avoid System.exit in tests. It's
probably okay here as it always runs in othervm mode but in other
modes a System.exit(0) will be flagged by jtreg and will require it
spin up another VM.
No System.exit in this webrev any more. The test should still run in
othervm though, since it uses special VM option
"-XX:MaxDirectMemorySize=128m". Without it there might be to much direct
memory available by default on some machine (like mine with 16GB of RAM)
to provoke an error in 5 seconds time...
I completely agree with separating the mapped buffers issue to a
separate issue.
Thanks again for running with this one (it goes back to original
implementation in JDK 1.4).
-Alan.
I think I'll need another official review before pushing this.
Regards, Peter
