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

Hi Kim, Roger, Mandy, Resending with correct From: field to reach the list too... On 02/24/2016 12:22 AM, Kim Barrett wrote: On Feb 23, 2016, at 11:35 AM, Peter Levart wrote: Hi Roger, Mandy, Here's another webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.05

RE: RFR 8150470: JCK: api/xsl/conf/copy/copy19 test failure

Thanks Aleksej From: Aleksej Efimov [mailto:aleksej.efi...@oracle.com] Sent: Mittwoch, 24. Februar 2016 13:36 To: Langer, Christoph Cc: Joe Wang ; core-libs-dev@openjdk.java.net Subject: Re: RFR 8150470: JCK: api/xsl/conf/copy/copy19 test failure Hi Christoph, The changes looks good to me too. I

Re: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

For the record this looks fine to me too. Thanks, David - On 18/02/2016 1:17 AM, cheleswer sahu wrote: Hi, I have made changes in the property name (jdk.lang.processReaperUseDefaultStackSize) and code as suggested in the earlier reviews. --- old/src/java.base/share/classes/java/lang/Proc

RFR: 8144062: Determine appropriate module for jdk.Version

Hi, Alan, Mandy, and Mark. After exploring a few module options (jdk.Version, jdk.dev [0]), it looks like the best choice is to move jdk.Version to java.lang.Runtime.Version (a nested class of Runtime). It supports the values returned by the java.{vm.}?version and java.{vm.}?specification.ver

Re: JDK 9 RFR of JDK-8150608: Mark BashStreams.java as intermittently failing and put to ProblemList

Hi Amy, +1 for me but I am not a JDK 9 Reviewer. Thanks, Brian On Feb 24, 2016, at 5:49 PM, Amy Lu wrote: > java/nio/charset/coders/BashStreams.java > > This test is known to fail intermittently, this patch is to mark the test > accordingly with keyword 'intermittent’ and put it to ProblemL

JDK 9 RFR of JDK-8150608: Mark BashStreams.java as intermittently failing and put to ProblemList

java/nio/charset/coders/BashStreams.java This test is known to fail intermittently, this patch is to mark the test accordingly with keyword 'intermittent’ and put it to ProblemList.txt for further investigation. bug: https://bugs.openjdk.java.net/browse/JDK-8150608 webrev: http://cr.openjdk.j

[9] RFR: 8150174: Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT)

Hi, Please, review the bulk update of JAX-WS/B from upstream projects: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8150174/9/00/ Details (list of fixed issues) can be found in bug report: https://bugs.openjdk.java.net/browse/JDK-8150174 The following test sets were executed over JDK9

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi Thomas, On 2/24/2016 12:30 PM, Thomas Stüfe wrote: Hi all, please take a look at this proposed fix. The bug: https://bugs.openjdk.java.net/browse/JDK-8150460 The Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/ Basically, the file descriptor

RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi all, please take a look at this proposed fix. The bug: https://bugs.openjdk.java.net/browse/JDK-8150460 The Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/ Basically, the file descriptor table implemented in linux_close.c may not work for RLIMI

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On 24/02/16 15:56, mark.reinh...@oracle.com wrote: > 2016/2/23 22:22 -0800, Gil Tene : >> ... >> >> Let's just go with it. >> >> Thread.onSpinWait() FTW! > > I agree. The "on" prefix is not exclusively reserved for APIs that > deliver event objects, and in this context it clarifies the meaning >

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

Hi, Moving cleanNextPending to the CleanerImpl is ok but exposes more of the CleanerImpl to the rest of java.base internals; loosing a bit of encapsulation. As for the calls to Reference.tryHandlePending(false), the existing code in Bits to reserveMemory is called on arbitrary threads (whoev

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On 24/02/2016 18:56, mark.reinh...@oracle.com wrote: 2016/2/23 22:22 -0800, Gil Tene : ... Let's just go with it. Thread.onSpinWait() FTW! I agree. The "on" prefix is not exclusively reserved for APIs that deliver event objects, and in this context it clarifies the meaning of the method. -

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

Looks like you have Mark's approval, so we're done :). On Wed, Feb 24, 2016 at 11:06 AM, Ivan Krylov wrote: > On 24/02/2016 18:20, Vitaly Davidovich wrote: > >> If you want, run a poll to get a better feel for what others may think. >> Doug did that recently for some CompletableFuture behavior c

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On 24/02/2016 18:20, Vitaly Davidovich wrote: If you want, run a poll to get a better feel for what others may think. Doug did that recently for some CompletableFuture behavior change proposals. Ultimately, I don't make the call on this anyway so I'm just giving you my opinion as a would-be use

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

2016/2/23 22:22 -0800, Gil Tene : > ... > > Let's just go with it. > > Thread.onSpinWait() FTW! I agree. The "on" prefix is not exclusively reserved for APIs that deliver event objects, and in this context it clarifies the meaning of the method. - Mark

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On Wednesday, February 24, 2016, Gil Tene wrote: > onXXX is VERY relevant to this situation. And it's exactly that precedent > and common convention for event notification calls that drove the choice of > onSpinWait as a method name. onSpinWait() it is delivering a notification > [from the callin

Re: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8

On Feb 19, 2016, at 1:55 PM, Nikolay Gorshkov mailto:niko...@azulsystems.com>> wrote: Hi Sherman, Sean, Could you please help with making progress on this code review request? This fix is waiting for review since October. Webrev for jdk7u: http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/w

Re: RFR 8150470: JCK: api/xsl/conf/copy/copy19 test failure

Hi Christoph, The changes looks good to me too. I will push them shortly today. With Best Regards, Aleksej On 02/24/2016 02:49 AM, Langer, Christoph wrote: Hi, the changeset for 8149915 (enabling validate-annotations feature for xsd schema with annotation causes NPE) introduced a regression.

Re: RFR 8145635 : Add TCP_QUICKACK socket option

On 24/02/2016 09:16, vyom wrote: Hi All, Please review my code changes for the below issue. Bug: JDK-8145635 : Add TCP_QUICKACK socket option Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.0/index.html Currently TCP_QUICKACK is only supported on Linux( since Linux 2.4.4) so i i

RFR 8145635 : Add TCP_QUICKACK socket option

Hi All, Please review my code changes for the below issue. Bug: JDK-8145635 : Add TCP_QUICKACK socket option Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.0/index.html Currently TCP_QUICKACK is only supported

Re: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor

Looks good to me. Masayoshi On 2/24/2016 4:40 PM, Ramanand Patil wrote: Hi all, Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104 Bug Description: DateFormatSymbols caches its own instance and calls this.clone() in the constructor. Because of this, any subclass im