Re: RFC: Adding ConcurrentModificationException for HashMap.computeIfAbsent(), and JDK-8071667

Hi, Paul On 3/10/15 8:29 AM, Paul Sandoz wrote: On the Map.compute* methods. Perhaps we can reuse similar language to that we added for Matcher: * The mapping function should not modify this map during computation. * This method will, on a best-effort basis, throw a * ConcurrentModification i

Re: JEP 102 Process Updates revised API draft

Hi Peter, On 3/10/2015 2:57 PM, Peter Levart wrote: Hi Roger, Thanks for bearing with me... And me, as I find the route among the language, type system, compatibility issues, and os intricacies. On 03/10/2015 06:27 PM, Roger Riggs wrote: I think current ProcessHandle is a mix of specificati

Re: JEP 102 Process Updates revised API draft

On 03/10/2015 06:32 PM, Roger Riggs wrote: Can you point me to the alternative Process implementations outside the JDK? I've seen a bit of flak about it not being the right API and if its not right we should not extend it. Roger This will continue to work, since it's just a wrapper around a

Re: JDK 9 RFR of JDK-8074870: Really add javax/xml/jaxp/testng/validation to othervm.dirs in TEST.ROOT

Hi Joe, Looks fine. Roger On 3/10/2015 2:12 PM, joe darcy wrote: Hello, Recently I sent out a review for JDK-8074714 : Add javax/xml/jaxp/testng/validation to othervm.dirs in TEST.ROOT http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032151.html However, I actually a

Re: RFR: JDK-8074578 Document memory visibility effects of some Unsafe methods

I agree with Andrew that the Unsafe API matters, and there are many implementations of it (even multiple within openjdk itself!). I still know of no reason why my proposed spec is wrong. If C11 support was good and ubiquitous, I would recommend using atomic_compare_exchange_strong or C++ equivale

Unsafe.{get,put}-X-Unaligned performance

I've been measuring the performance after this patch, and as you might expect it's always much better with UseUnalignedAccesses. However, we can sometimes get performance regressions, albeit in some fairly contrived cases. I have a test which repeatedly loads a {long,int,short} at some random off

Re: JEP 102 Process Updates revised API draft

Hi Roger, Thanks for bearing with me... On 03/10/2015 06:27 PM, Roger Riggs wrote: I think current ProcessHandle is a mix of specification and partial implementation that does not help in any way to hypothetical external implementations. It effectively disables any consistent alternative impl

RE: Compression acceleration for Java

Yes, it will be nice if the OpenJDK and Oracle builds for Linux/Solaris used the system rather than the bundled zlib. In which case, there will be no need for JVM command line option. Also the HW/SW compression accelerators can then be used easily with Java. Is it possible to get this feature

JDK 9 RFR of JDK-8074870: Really add javax/xml/jaxp/testng/validation to othervm.dirs in TEST.ROOT

Hello, Recently I sent out a review for JDK-8074714 : Add javax/xml/jaxp/testng/validation to othervm.dirs in TEST.ROOT http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032151.html However, I actually added the directory in question to the exclusiveAccess.dirs property rat

Re: JEP 102 Process Updates revised API draft

Hi Peter, Differing design approaches... On 3/10/2015 12:37 PM, Peter Levart wrote: On 03/10/2015 10:50 AM, Paul Sandoz wrote: On Mar 6, 2015, at 7:58 PM, Roger Riggs wrote: 2) I know there has been a lot of discussion about the use of CF, but I have a few more comments: a) Bo

Re: Why is java.awt.image.BufferedImage not serializable ?

Bonjour, I think your question would be better directed to the 2d-dev list: http://mail.openjdk.java.net/mailman/listinfo/2d-dev Merci, Brian On Mar 9, 2015, at 7:58 PM, Jean-François Savard wrote: > I believe java.awt.image.BufferedImage (and all java images type) are not > serializable si

Why is java.awt.image.BufferedImage not serializable ?

Hi, I believe java.awt.image.BufferedImage (and all java images type) are not serializable simply because it is illogical to serializable an Image file, as the point of serializing is to keep something as a file independent of the JVM. Which is already the case for a normal image file. Would yo

RE: [concurrency-interest] Why not "weakNanoTime" for jdk9?

Aleksey Shipilev wrote: > It would really help if you list what problems weakNanoTime is > supposed to solve. I was talking to Martin about this idea recently so I'll take a shot at describing why it's appealing to me (with the usual disclaimer that I know I'm much less of an expert than most oth

Re: JEP 102 Process Updates revised API draft

On 03/10/2015 10:50 AM, Paul Sandoz wrote: On Mar 6, 2015, at 7:58 PM, Roger Riggs wrote: 2) I know there has been a lot of discussion about the use of CF, but I have a few more comments: a) Both onExit and onProcessExit are implemented to unconditionally throw UOE. Is t

RFR (XS) 8074761: Empty optional parameters of LDAP query are not interpreted as empty

Hi All, Please review the patch for LdapURL. Patch fixes the parsing of query part of LDAP URL, leaving empty optional fields as null instead of "". Webrev: http://goo.gl/OO0V38 Bug: https://bugs.openjdk.java.net/browse/JDK-8074761 JTreg: http://goo.gl/ermmoh Details: RFC 2255 [1] allows any

Re: RFC: Adding ConcurrentModificationException for HashMap.computeIfAbsent(), and JDK-8071667

Hi Brent, On the Map.compute* methods. Perhaps we can reuse similar language to that we added for Matcher: The mapping function should not modify this map during computation. This method will, on a best-effort basis, throw a ConcurrentModification if such modification is detected. It's te

Re: JEP 102 Process Updates revised API draft

On Mar 10, 2015, at 3:16 PM, Roger Riggs wrote: > On 3/10/2015 5:50 AM, Paul Sandoz wrote: >> On Mar 6, 2015, at 7:58 PM, Roger Riggs wrote: 2) I know there has been a lot of discussion about the use of CF, but I have a few more comments: a) Both onExit and onProcessEx

Re: JEP 102 Process Updates revised API draft

Hi Paul, On 3/10/2015 5:50 AM, Paul Sandoz wrote: On Mar 6, 2015, at 7:58 PM, Roger Riggs wrote: 2) I know there has been a lot of discussion about the use of CF, but I have a few more comments: a) Both onExit and onProcessExit are implemented to unconditionally throw U

Re: JEP 102 Process Updates revised API draft

Hi Peter, On 3/10/2015 5:17 AM, Peter Levart wrote: Hi, On 03/09/2015 07:46 PM, Roger Riggs wrote: Hi Jason, Comparing with startInstant is a possibility, assuming it is cached in the ProcessHandle and increases the cost of creating ProcessHandles since it needs to be parsed from /proc file

Re: JEP 238: Multi-Version JAR Files

Sorry for the late reply, getting through email backlogs... On Mar 1, 2015, at 11:41 AM, Florian Weimer wrote: > On 02/27/2015 06:16 PM, Paul Sandoz wrote: >> On Feb 27, 2015, at 4:47 PM, Florian Weimer wrote: >>> I really don't think this tooling support will provide sufficient >>> enticement

Re: RFR(S): JDK-8073584 Native compilation warning in unpack code

On 10/03/2015 5:53 PM, Dmitry Samersoff wrote: David at all, May I consider the fix as reviewed and continue with integration? Seems okay to me. David -Dmitry On 2015-02-24 05:23, David Holmes wrote: On 24/02/2015 12:02 AM, Dmitry Samersoff wrote: Hi Everyone, Webrev updated in-place (

Re: JEP 102 Process Updates revised API draft

On Mar 6, 2015, at 7:58 PM, Roger Riggs wrote: >> 2) I know there has been a lot of discussion about the use of CF, >> but I have a few more comments: >> a) Both onExit and onProcessExit are implemented to unconditionally >> throw UOE. Is the intention to make the implementati

Re: JEP 102 Process Updates revised API draft

Hi, On 03/09/2015 07:46 PM, Roger Riggs wrote: Hi Jason, Comparing with startInstant is a possibility, assuming it is cached in the ProcessHandle and increases the cost of creating ProcessHandles since it needs to be parsed from /proc files. Unless it is obtained lazily and then cached. Int

Re: RFR(S): JDK-8073584 Native compilation warning in unpack code

David at all, May I consider the fix as reviewed and continue with integration? -Dmitry On 2015-02-24 05:23, David Holmes wrote: > On 24/02/2015 12:02 AM, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Webrev updated in-place (press shift-reload) >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-

Re: RFR: JDK-8074578 Document memory visibility effects of some Unsafe methods

On 10/03/15 01:30, David Holmes wrote: > On 10/03/2015 2:21 AM, Martin Buchholz wrote: >> On Mon, Mar 9, 2015 at 4:13 AM, David Holmes > > wrote: >> >> On 9/03/2015 7:27 PM, Andrew Haley wrote: >> >> >> But who is to say that is the specification for the Unsa

Re: RFR: JDK-8074578 Document memory visibility effects of some Unsafe methods

On 10/03/15 01:38, David Holmes wrote: > PS. You state: "Corresponds to C11 atomic_compare_exchange_strong." Yet > that would match with the full bi-directional fences of the VM > implementation (due to memory_order_seq_cst), not a volatile read > followed by a volatile write (which would be mem