Fwd: RFR 8150829: Enhanced drop-args, identity and default constant, varargs adjustment

Gentle Reminder! Forwarded Message Subject: RFR 8150829: Enhanced drop-args, identity and default constant, varargs adjustment Date: Tue, 22 Mar 2016 17:11:00 +0530 From: shilpi.rast...@oracle.com To: core-libs-dev@openjdk.java.net, John Rose

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

> On Mar 23, 2016, at 4:42 PM, Peter Levart wrote: > > Hi Kim, > > Thinking more about your approach. Basically your idea is to detect that > there are no more unprocessed but pending or enqueued Cleanables by timing > out on waiting for next Cleanable to be processed.

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

On 03/23/2016 09:40 PM, Kim Barrett wrote: On Mar 23, 2016, at 3:33 PM, Peter Levart wrote: Hi Kim, On 03/23/2016 07:55 PM, Kim Barrett wrote: On Mar 23, 2016, at 10:02 AM, Peter Levart wrote: ...so I checked what it would be needed if

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

Hi Kim, Thinking more about your approach. Basically your idea is to detect that there are no more unprocessed but pending or enqueued Cleanables by timing out on waiting for next Cleanable to be processed. In that case the timeout should be reset when each Cleanable is detected to be

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

> On Mar 23, 2016, at 3:33 PM, Peter Levart wrote: > > Hi Kim, > > On 03/23/2016 07:55 PM, Kim Barrett wrote: >>> On Mar 23, 2016, at 10:02 AM, Peter Levart >>> wrote: >>> ...so I checked what it would be needed if there was such >>>

Re: RFR [9] 8152277: Move URLClassPath.pathToURLs(String) to RegistryImpl

On 23/03/2016 15:46, Chris Hegarty wrote: Update webrev: http://cr.openjdk.java.net/~chegar/8152277/ I'm not sure under what circumstances toRealPath can fail, but I tried to be consistent with the old behavior. This looks okay to me. One thing you could do is replace "// use the

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

Hi Kim, On 03/23/2016 07:55 PM, Kim Barrett wrote: On Mar 23, 2016, at 10:02 AM, Peter Levart wrote: ...so I checked what it would be needed if there was such getPendingReferences() native method. It turns out that a single native method would not be enough to support

Re: Code Review Request, 8152237 Support BigInteger.TWO

Ok, here's a test... with just the following change: diff -r 9ea9fb3c0c88 src/java.base/share/classes/java/math/BigInteger.java --- a/src/java.base/share/classes/java/math/BigInteger.java Wed Mar 23 18:24:35 2016 +0100 +++ b/src/java.base/share/classes/java/math/BigInteger.java Wed

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

> On Mar 23, 2016, at 10:02 AM, Peter Levart wrote: > ...so I checked what it would be needed if there was such > getPendingReferences() native method. It turns out that a single native > method would not be enough to support the precise direct ByteBuffer > allocation.

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

Hi, This one was discussed back to Feb, and have been waiting for the devkit clearance from the build-dev, which has just been resolved [1]. So here is webrev again. http://cr.openjdk.java.net/~sherman/8031767/webrev thanks! Sherman [1] https://bugs.openjdk.java.net/browse/JDK-8149545 btw,

Re: Code Review Request, 8152237 Support BigInteger.TWO

Hi Xuelei, On 03/23/2016 04:26 AM, Xuelei Fan wrote: Hi, Please review the update for the supporting of BigInteger.TWO: http://cr.openjdk.java.net/~xuelei/8152237/webrev/ BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The

Re: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants

(adding core-libs) On 2016-03-23 12:13, Erik Joelsson wrote: In the gensrc step for java.base, we generate a couple of java classes with the purpose of extracting native constants from the system. We currently do this by compiling a C program that when run, generates the java source file. The

Re: [8u-dev] Request for approval: 8145039: JAXB marshaller fails with ClassCastException on classes generated by xjc

looks fine On Mar 23, 2016, at 8:39 AM, Aleksej Efimov wrote: > David, > > Thanks for approval. > > Adding corelibs-dev for getting code review. Can someone, please, take a look > at the partially backported changes [1]? > > Best Regards, > Aleksej > > [1]

Re: RFR [9] 8152277: Move URLClassPath.pathToURLs(String) to RegistryImpl

On 21/03/16 18:35, Alan Bateman wrote: On 21/03/2016 17:45, Chris Hegarty wrote: In the context of 8149122 & 8152190 it was noticed that sun.rmi.registry.RegistryImpl is the only invoker of URLClassPath::pathToURLs. Rather that adding a qualified export to java.rmi for this, it makes sense to

Re: Review request for 8151571: System/LoggerFinder tests fail after JDK-8149925

> On Mar 23, 2016, at 4:54 AM, Alan Bateman wrote: > > On 22/03/2016 18:41, Mandy Chung wrote: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/ >> >> This restores the change in NativeBuffer to use the common Cleaner created >> by the system.

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

Hi Peter, On 2016-03-23 15:02, Peter Levart wrote: Hi Per, Kim, On 03/22/2016 10:24 AM, Per Liden wrote: So, I imagine the ReferenceHandler could do something like this: while (true) { // getPendingReferences() is a downcall to the VM which // blocks until the pending list becomes

Re: Code Review Request, 8152237 Support BigInteger.TWO

Hi, How much is the performance improvement? I see that BigInteger.valueOf (n <= 16) have predefined constants and returns an existing instance. Adding TWO is ok. Roger On 3/23/2016 9:44 AM, Wang Weijun wrote: On Mar 23, 2016, at 7:23 PM, Xuelei Fan wrote: On

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

Hi Per, Kim, On 03/22/2016 10:24 AM, Per Liden wrote: So, I imagine the ReferenceHandler could do something like this: while (true) { // getPendingReferences() is a downcall to the VM which // blocks until the pending list becomes non-empty and // returns the whole list,

Re: Code Review Request, 8152237 Support BigInteger.TWO

Thanks! Xuelei On 3/23/2016 9:44 PM, Wang Weijun wrote: > >> On Mar 23, 2016, at 7:23 PM, Xuelei Fan wrote: >> >> On 3/23/2016 5:44 PM, Wang Weijun wrote: >>> Then why not fix the 2 bugs in a single changeset? >>> >> Both need spec update approval. As they are

Re: RFR: 8151876: (tz) Support tzdata2016b

Sorry for this belated response. I prefer to follow the tzdata abbreviations, like "+04". But that would require some major changes. An option would be not to define time zone names for the new zones with the +hh format. Thanks, Masayoshi On 3/17/2016 4:38 AM, Ramanand Patil wrote: Hi all,

Re: Code Review Request, 8152237 Support BigInteger.TWO

> On Mar 23, 2016, at 7:23 PM, Xuelei Fan wrote: > > On 3/23/2016 5:44 PM, Wang Weijun wrote: >> Then why not fix the 2 bugs in a single changeset? >> > Both need spec update approval. As they are completely different spec > update, better to update in 2 enhancements. >

Re: Code Review Request, 8152237 Support BigInteger.TWO

Hi Attila, Good catch about the comparing. I updated the code in my local workspace, and I would ask for code review in another enhancement update soon. Thanks, Xuelei On 3/23/2016 9:15 PM, Attila Szegedi wrote: > Sorry for beating the dead horse of ObjectIdentifier.java change, but > I’d

Re: Review request for 8151571: System/LoggerFinder tests fail after JDK-8149925

Hi Mandy, On 22/03/16 18:41, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/ I think this is fine. ( I also agree with Alan's comment ) Just a few minor, subjective, comments: - Maybe update the CleanerFactory class-level docs, OpenJDK modules ->

Re: Code Review Request, 8152237 Support BigInteger.TWO

Sorry for beating the dead horse of ObjectIdentifier.java change, but I’d suggest that if that code is later revisited, it be changed to "first.compareTo(BigInteger.TWO) > 0" instead of “… == 1”. Comparing the return value of compareTo to zero (instead of relying on specific set of return

Re: [8u-dev] Request for approval: 8145039: JAXB marshaller fails with ClassCastException on classes generated by xjc

David, Thanks for approval. Adding corelibs-dev for getting code review. Can someone, please, take a look at the partially backported changes [1]? Best Regards, Aleksej [1] http://cr.openjdk.java.net/~aefimov/8145039/8/00 On 03/23/2016 02:16 PM, David Buck wrote: approved for push to

Re: JAXP default implementation and JDK-8152063

On 23/03/2016 12:12, David M. Lloyd wrote: : I wonder why JAXP is not considered to be upgradeable at this point? MR 3 of JSR 206 (or JAXP 1.6 as it was called) in late 2013 announced its end as a standalone technology. Going forward then the proposal is that it be subsumed into the

Re: JAXP default implementation and JDK-8152063

On 03/22/2016 08:59 AM, Daniel Fuchs wrote: Hi David, On 22/03/16 13:53, David M. Lloyd wrote: Am I understanding it correctly that you're pointing the system property to a "proxy" as stated in JDK-8152063, not an actual implementation? So it's sort of a provider-locating mechanism outside of

Re: Review request for 8151571: System/LoggerFinder tests fail after JDK-8149925

On 22/03/2016 18:41, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/ This restores the change in NativeBuffer to use the common Cleaner created by the system. JDK-8149925 causes InnocuousThread be created early during startup before the system class

Re: Code Review Request, 8152237 Support BigInteger.TWO

On 3/23/2016 5:44 PM, Wang Weijun wrote: > Then why not fix the 2 bugs in a single changeset? > Both need spec update approval. As they are completely different spec update, better to update in 2 enhancements. As you have concerns here, I removed ObjectIdentifier.java from this update. See the

Re: Code Review Request, 8152237 Support BigInteger.TWO

Then why not fix the 2 bugs in a single changeset? --Max > 在 2016年3月23日，17:06，Xuelei Fan 写道： > >> On 3/23/2016 3:34 PM, Wang Weijun wrote: >> >>> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote: >>> >>> On 3/23/2016 12:10 PM, Wang Weijun wrote:

Re: Code Review Request, 8152237 Support BigInteger.TWO

On 3/23/2016 3:34 PM, Wang Weijun wrote: > >> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote: >> >> On 3/23/2016 12:10 PM, Wang Weijun wrote: >>> Only 3 files touched. Are you going to make the >>> s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

Hi, On 2016-03-23 08:13, Peter Levart wrote: On 03/22/2016 10:28 PM, Kim Barrett wrote: On Mar 22, 2016, at 5:24 AM, Per Liden wrote: One thing I like about this approach is that it's only the ReferenceHandler thread that pops of elements from the pending list and

Re: Code Review Request, 8152237 Support BigInteger.TWO

> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote: > > On 3/23/2016 12:10 PM, Wang Weijun wrote: >> Only 3 files touched. Are you going to make the >> s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another >> bug fix? >> > There are also uses in

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

On 03/22/2016 10:28 PM, Kim Barrett wrote: On Mar 22, 2016, at 5:24 AM, Per Liden wrote: One thing I like about this approach is that it's only the ReferenceHandler thread that pops of elements from the pending list and enqueues them. That simplifies things a lot. I