Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Hi everyone, The questions and suggestions regarding this proposal (JDK-8153111) are interesting and useful. We are still digesting the feedback; next week we'll do our best to respond to items raised and add to the discussion. I hope this

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Apr 1, 2016, at 4:31 PM, Roger Riggs wrote: > > Hi Peter, > > I overlooked the introduction of another nested class (Task) to handle the > cleanup. > But there are too many changes to see which ones solve a single problem. > > Sorry to make more work, but I think

Re: RFR [9] 8153181: Examine sun.misc.VMSupport

Hi Chris, Would jdk.internal.vm be appropriate for this VMSupoprt class? VMSupport::getAgentProperties simply calls JVM_InitAgentProperties. java.management could call JVM_InitAgentProperties directly. src/jdk.jdwp.agent/share/native/libjdwp/util.c JDWP calls it and needs to be updated.

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, I overlooked the introduction of another nested class (Task) to handle the cleanup. But there are too many changes to see which ones solve a single problem. Sorry to make more work, but I think we need to go back to the minimum necessary change to make progress on this. Omit all of

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, Thanks for the diffs to look at. Two observations on the changes. - The Cleaner instance was intentionally and necessarily different than the CleanerImpl to enable the CleanerImpl and its thread to terminate if the Cleaner is not longer referenced. Folding them into a single

Re: RFR: 8153317: Two jimage tests have been failing since JDK-8152641 was fixed

Hello Joe, and thanks! The change is in the plugin and not the test, though, so might be as good as it gets (I've verified all jlink plugin tests work with this). The surprising thing here to me is why these tests was running the plugin twice on the same (exploded) image since regurgitating

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

Hi Steve, this looks good to me! Thanks! /Claes On 2016-04-01 22:37, Steve Drach wrote: Hi, Please review this simple fix to require that the jar manifest Multi-Release attribute has a value of “true" in order to be effective, i.e. to assert the jar is a multi-release jar. issue:

RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

Hi, Please review this simple fix to require that the jar manifest Multi-Release attribute has a value of “true" in order to be effective, i.e. to assert the jar is a multi-release jar. issue: https://bugs.openjdk.java.net/browse/JDK-8153213

Re: RFR: 8153317: Two jimage tests have been failing since JDK-8152641 was fixed

Hello Claes, I'll approve the test change in the interests of getting the tests back to green, but it does sound like some more investigation is warranted into what is going on. In other words, running down the root cause to make sure the same bad effect won't show up elsewhere. Thanks,

RFR: 8153317: Two jimage tests have been failing since JDK-8152641 was fixed

Hi, seems my recent push for JDK-8152641 broke a jimage test or two. While I think these test seem a bit odd, it's apparent that checking that we're not adding the same resource twice is enough to make the tests happy for now: Webrev: http://cr.openjdk.java.net/~redestad/8153317/webrev.01/

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

On 04/01/2016 06:05 PM, David M. Lloyd wrote: > Without a resolution to https://bugs.openjdk.java.net/browse/JDK-8008240 > (atomics for buffers) or > https://bugs.openjdk.java.net/browse/JDK-6476827 (memory consistency > properties of buffers), how meaningful is this? That's on the list of

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Without a resolution to https://bugs.openjdk.java.net/browse/JDK-8008240 (atomics for buffers) or https://bugs.openjdk.java.net/browse/JDK-6476827 (memory consistency properties of buffers), how meaningful is this? On 03/31/2016 07:06 PM, Hans Boehm wrote: The expectation would be that such

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 04/01/2016 06:08 PM, Peter Levart wrote: On 04/01/2016 05:18 PM, Peter Levart wrote: @Roger: ... About entanglement between nio Bits and ExtendedCleaner.retryWhileHelpingClean(). It is the same level of entanglement as between the DirectByteBuffer constructor and Cleaner.register().

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 04/01/2016 05:18 PM, Peter Levart wrote: So I'm going to propose a solution for #1 while still keeping the rest of webrev unchanged for now and will try to address other issuer later. Here's new webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.12.part2/

RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hello! Please review and sponsor the following patch: http://cr.openjdk.java.net/~tvaleev/webrev/8153293/r1/ The patch preserves more characteristics on primitive stream operations: IntStream/LongStream/DoubleStream.boxed() preserves SORTED and DISTINCT IntStream.asLongStream() preserves SORTED

Bug id : 8140747 - Data corruption when parsing XML using StAX/Xerces

Hello, Encountered this bug on our server and after some investigations I was able to find the bug reported here https://bugs.openjdk.java.net/browse/JDK-8140747. It seems that you were not able to reproduce on the Java versions mentioned in the bug's description. I am able to reproduce it on

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 04/01/2016 05:18 PM, Peter Levart wrote: @Roger: ... About entanglement between nio Bits and ExtendedCleaner.retryWhileHelpingClean(). It is the same level of entanglement as between the DirectByteBuffer constructor and Cleaner.register(). In both occasions an action is provided to the

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Mandy, Roger, On 04/01/2016 06:07 AM, Mandy Chung wrote: Hi Peter, I found this thread has grown to discuss several relevant issues that can be separated. 1. Assist cleaner to deallocate direct byte buffer (JDK-6857566) 2. Replace direct byte buffer with java.lang.ref.Cleaner 3.

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

On 2016-04-01 16:57, Mandy Chung wrote: On Apr 1, 2016, at 5:32 AM, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/8152641/webrev.06/ Looks good except the new test with 2015 copyright start year. Fixed. Thanks Mandy! /Claes

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

> On Apr 1, 2016, at 5:32 AM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/8152641/webrev.06/ > Looks good except the new test with 2015 copyright start year. > > [1] Mandy filed https://bugs.openjdk.java.net/browse/JDK-8153238 to improve > this

Re: RFR: 8153262: javax/xml/bind/marshal/8134111/UnmarshalTest.java fails

Looks fine. Regards, Sean. On 01/04/16 14:01, Aleksej Efimov wrote: Hi, The push for JDK-8134111 missed one test file. Please, review and approve the addition of missing ObjectFactory.java file. Webrev with added file: http://cr.openjdk.java.net/~aefimov/8153262/00 Thanks, Aleksej

Re: RFR: 8153262: javax/xml/bind/marshal/8134111/UnmarshalTest.java fails

Looks fine. Thank you for the quick fix ! ( As I'm not openjdk reviewer, please wait for reviewer's feedback. ) Thanks, Amy On 4/1/16 9:01 PM, Aleksej Efimov wrote: Hi, The push for JDK-8134111 missed one test file. Please, review and approve the addition of missing ObjectFactory.java file.

RFR: 8153262: javax/xml/bind/marshal/8134111/UnmarshalTest.java fails

Hi, The push for JDK-8134111 missed one test file. Please, review and approve the addition of missing ObjectFactory.java file. Webrev with added file: http://cr.openjdk.java.net/~aefimov/8153262/00 Thanks, Aleksej

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

On 04/01/2016 09:54 AM, Attila Szegedi wrote: > I can think of several differences. For one, you can’t presume the > availability of a filesystem (Java doesn’t require that the host > system give it access to a filesystem), nor the ability of the > filesystem to expose all desired kinds of memory

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

Hi Mandy et al, On 2016-04-01 01:10, Mandy Chung wrote: GenerateBMHClassesPlugin::configure The plugin should validate of the input argument and throw an exception if it’s invalid. The plugin API is still being revised and JDK-8152800 is related to the exception case. The existing

https://bugs.openjdk.java.net/browse/JI-9032379

Hi, Need some suggestion for this issue (2nd part). Thanks Abhijit

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

I can think of several differences. For one, you can’t presume the availability of a filesystem (Java doesn’t require that the host system give it access to a filesystem), nor the ability of the filesystem to expose all desired kinds of memory as files. Next, every such solution is OS specific

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

On 31/03/16 22:14, Dohrmann, Steve wrote: > This is a JDK 9 proposal to support allocation of direct > java.nio.ByteBuffer instances backed by memory other than off-heap > RAM. I must be missing something. How is this different from exposing special memory via the filesystem and mapping a file?