Re: RFR (S) 8150180: String.value contents should be trusted

> On Feb 19, 2016, at 1:22 PM, Aleksey Shipilev > wrote: > > On 02/20/2016 01:40 AM, Christian Thalinger wrote: >>> On Feb 19, 2016, at 9:03 AM, John Rose wrote: >>> On Feb 19, 2016, at 9:57 AM, Christian Thalinger >>>

Re: RFR (S) 8150180: String.value contents should be trusted

On 02/20/2016 01:40 AM, Christian Thalinger wrote: >> On Feb 19, 2016, at 9:03 AM, John Rose wrote: >> On Feb 19, 2016, at 9:57 AM, Christian Thalinger >> > >> wrote: >>> Why don’t you change the

Re: RFR (S) 8150180: String.value contents should be trusted

On Feb 19, 2016, at 2:40 PM, Christian Thalinger wrote: > >> >> On Feb 19, 2016, at 9:03 AM, John Rose > > wrote: >> >> On Feb 19, 2016, at 9:57 AM, Christian Thalinger >>

Re: RFR (S) 8150180: String.value contents should be trusted

> On Feb 19, 2016, at 9:03 AM, John Rose wrote: > > On Feb 19, 2016, at 9:57 AM, Christian Thalinger > > > wrote: >> >> Why don’t you change the values to: >> >>static final byte LATIN1 = 1;

Re: JDK 9 RFR of 8150206: Demote LFMultiThreadCachingTest.java to tier 2 until resolution of JDK-8150014

I will commit by Monday. The only other change I'm thinking of would be to move the Unsafe initialization to the top of file (i.e. beginning of ) instead of bottom of file where we've traditionally placed it. Here a static method call that used U found it to be null - we must still be inside ,

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

> On Feb 19, 2016, at 10:59 AM, Iris Clark wrote: > > Hi, Mandy. > >> Before Verona, sun.misc.Version was generated at build time and was intended >> to set up the system properties about “java.version”, >> “java.runtime.version”, “java.runtime.name”. Did Verona

Re: RFR (S) 8150180: String.value contents should be trusted

On Feb 19, 2016, at 9:57 AM, Christian Thalinger wrote: > > Why don’t you change the values to: > >static final byte LATIN1 = 1; >static final byte UTF16 = 2; Not sure what you are asking, but here's my take on why 0,1 is the (slight) winner. The

RE: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

Hi, Mandy. > Before Verona, sun.misc.Version was generated at build time and was intended > to set up the system properties about “java.version”, “java.runtime.version”, > “java.runtime.name”. Did Verona change the logic such that this class is no > longer needed? Verona did not change logic

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

> On Feb 19, 2016, at 9:52 AM, Iris Clark wrote: > > Hi, Chris. > >>> I'm not the code maintainer, but I'd consider deprecating them. > >> Or just removing them. > > Agreed. Before Verona, sun.misc.Version was generated at build time and was intended to set up the

Re: JDK 9 RFR of 8150206: Demote LFMultiThreadCachingTest.java to tier 2 until resolution of JDK-8150014

Hello, I'm happy if Martin's delambdafication is the right solution. However, if that is not pushed by Monday Feb. 22, I'll want to go ahead and problem list the test. Thanks, -Joe On 2/19/2016 1:40 AM, Paul Sandoz wrote: Hi Martin, Your patch to TLR and SR looks good:

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

On 18/02/2016 15:52, Chris Hegarty wrote: sun.misc.Version is the core libraries part of a private interface with the JVM to query and set specific JVM version and capabilities, as well as being responsible for setting the system properties for "java.version”, "java.runtime.version", and

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

Hi Chris, Looks fine. (As a package private class in java.lang) Roger On 2/18/2016 10:52 AM, Chris Hegarty wrote: sun.misc.Version is the core libraries part of a private interface with the JVM to query and set specific JVM version and capabilities, as well as being responsible for setting

Re: RFR (S) 8150180: String.value contents should be trusted

> On Feb 19, 2016, at 4:05 AM, Peter Levart wrote: > > Hi, > > Just a stupid question. > > Your comment in String: > > 140 * @implNote Note this field is not {@link Stable}, because we want > 141 * LATIN1 (0) coder to fold too. {@link Stable} would not allow

RE: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

Hi, Chris. >> I'm not the code maintainer, but I'd consider deprecating them. > Or just removing them. Agreed. iris -Original Message- From: Chris Hegarty Sent: Friday, February 19, 2016 9:43 AM To: Iris Clark Cc: core-libs-dev Subject: Re: RFR [9] 8150162: Move sun.misc.Version to a

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

On 19 Feb 2016, at 17:40, Iris Clark wrote: > Hi, Chris. > >> http://cr.openjdk.java.net/~chegar/8150162/ > > From a versioning perspective, I think your changes are fine. Thanks Iris. > Regarding the choice of package, I think a package-private class in java.lang >

RE: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

Hi, Chris. > http://cr.openjdk.java.net/~chegar/8150162/ >From a versioning perspective, I think your changes are fine. Regarding the choice of package, I think a package-private class in java.lang is reasonable. Beyond initialization, I don't see any reason to use this class. The new

Re: RFR (S) 8150180: String.value contents should be trusted

On 02/19/2016 05:36 PM, Peter Levart wrote: > Yes, I understand the general principle of @Stable design and the role > of default value in @Stable fields. But given that: > > But never mind. This is just me thinking loud. Sure. The answer to those questions about @Stable is, as always: it works

Re: RFR (S) 8150180: String.value contents should be trusted

http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/ http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/ Looks good. Best regards, Vladimir Ivanov

Re: RFR (S) 8150180: String.value contents should be trusted

On 02/19/2016 03:07 PM, Aleksey Shipilev wrote: Hi Peter, On 02/19/2016 05:05 PM, Peter Levart wrote: Your comment in String: 140 * @implNote Note this field is not {@link Stable}, because we want 141 * LATIN1 (0) coder to fold too. {@link Stable} would not allow that, 142

Re: RFR (S) 8150180: String.value contents should be trusted

On 02/19/2016 03:42 PM, Vladimir Ivanov wrote: >>http://cr.openjdk.java.net/~shade/8150180/webrev.hs.01/ > > Why don't you check that index is also a constant? Otherwise, C2 can't > constant fold the loads. > > + if (value->is_Con()) { > +return false; > + } Right. Without that,

Re: RFR (S) 8150180: String.value contents should be trusted

Hi Peter, On 02/19/2016 05:05 PM, Peter Levart wrote: > Your comment in String: > > 140 * @implNote Note this field is not {@link Stable}, because we > want > 141 * LATIN1 (0) coder to fold too. {@link Stable} would not allow > that, > 142 * as it reserves the default value as

Re: RFR (S) 8150180: String.value contents should be trusted

Hi, Just a stupid question. Your comment in String: 140 * @implNote Note this field is not {@link Stable}, because we want 141 * LATIN1 (0) coder to fold too. {@link Stable} would not allow that, 142 * as it reserves the default value as "not initialized" value. 143

Re: RFR (S) 8150180: String.value contents should be trusted

http://cr.openjdk.java.net/~shade/8150180/webrev.hs.01/ Why don't you check that index is also a constant? Otherwise, C2 can't constant fold the loads. + if (value->is_Con()) { +return false; + } Best regards, Vladimir Ivanov

RFR (S) 8150180: String.value contents should be trusted

Hi, Please review a simple performance improvement in Strings: https://bugs.openjdk.java.net/browse/JDK-8150180 In short, we want VM to trust constant String contents, so that "Foo".charAt(0) is folded. As far as current Hotspot goes, this is only achievable with @Stable -- we need to trust

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

> On 19 Feb 2016, at 06:32, shilpi.rast...@oracle.com wrote: > > Hi All, > > Please see the updated webrev > http://cr.openjdk.java.net/~srastogi/8144931/webrev.03/ > +1 Paul.

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

Looks good. Best regards, Vladimir Ivanov On 2/19/16 8:32 AM, shilpi.rast...@oracle.com wrote: Please see the updated webrev http://cr.openjdk.java.net/~srastogi/8144931/webrev.03/

Re: JDK 9 RFR of 8150206: Demote LFMultiThreadCachingTest.java to tier 2 until resolution of JDK-8150014

Hi Martin, Your patch to TLR and SR looks good: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/unlambdafyBootstrap/jsr166-jdk9-integration- Sorry, i should of caught this in review, did notice the change to use lambdas but i forgot that this might cause issues

Re: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return JNI_VERSION_9

On 19/02/2016 03:10, Iris Clark wrote: Hi, Alan and Rachel. Here's a proposal for the new text for JEP 223: --- [ insert between existing sections "@since..." and "Mercurial..."] JNI Version The [JNI Specification][JNISpec] defines a constant representing the JNI version number. The