Re: RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12

Looks good. -Sundar On 02/01/19, 11:32 PM, Jim Laskey wrote: Looking for reviewers to make sure this CSR passes muster. CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 Thank you. Cheers, — Jim

Re: performance degradation in Array::newInstance on -XX:TieredStopAtLevel=1

Hi, what you're seeing specifically here is likely the native overhead: Array::newInstance calls into the native method Array::newArray, and C1 (TierStopAtLevel=1) doesn't have an intrinsic for this, while C2 does. C1 and the interpreter will instead call into

Re: enhanced for loop with multiple iteration variables

Thank you for your informative response. What you describe sounds very promising. (I hope the extra parentheses will not be required, though.) I take it that by “no runtime cost” you mean that something like the following would do only one heap allocation (for the iterator)? T[] array; for

performance degradation in Array::newInstance on -XX:TieredStopAtLevel=1

Hello, -XX:TieredStopAtLevel=1 flag is often used in some applications (e.g. Spring Boot based) to reduce start-up time. With this flag I've spotted huge performance degradation of Array::newInstance comparing to plain constructor call. I've used this benchmark @State(Scope.Thread)

Re: RFR: 8215412: Optimize PrintStream.println methods

Hi again, as expected not much of a difference on the test I was using (a small cost on the startup/warmup numbers due replacing a boolean check with a method call), but on a test that adds in a few extended PrintStreams and mixes those with use of System.out I can get a ~3-4% statistical

Re: RFR: 8215995: Add specialized toArray methods to immutable collections

On 2019-01-02 20:55, Martin Buchholz wrote: Which bounds check? On the second leg, you know you'll never hit the end of the array, so you can elide the check.  But hotspot may not be so clever and may re-insert it, in a slightly more expensive variant that has actual exception

Re: RFR: 8215995: Add specialized toArray methods to immutable collections

I'm happy with what you've got now. On Wed, Jan 2, 2019 at 11:46 AM Claes Redestad wrote: > Hi, > > On 2019-01-02 20:26, Martin Buchholz wrote: > > > > > > On Wed, Jan 2, 2019 at 11:10 AM Claes Redestad > > mailto:claes.redes...@oracle.com>> wrote: > > > > > > > I was surprised by the use

Re: RFR: 8215995: Add specialized toArray methods to immutable collections

Hi, On 2019-01-02 20:26, Martin Buchholz wrote: On Wed, Jan 2, 2019 at 11:10 AM Claes Redestad mailto:claes.redes...@oracle.com>> wrote: > I was surprised by the use of SALT in SetN. I'm guessing you could > improve SetN by adapting the tricky circular array traversal code

Re: RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12

Done. I've changed the Compatibility Kind to "source" (as I guess it better reflects the change, and the original CSR appears to have it as well) and added "Language Construct" to Interface Kind. Jan On 2.1.2019 19:02, Jim Laskey wrote: Looking for reviewers to make sure this CSR passes

Re: RFR: 8215995: Add specialized toArray methods to immutable collections

On Wed, Jan 2, 2019 at 11:10 AM Claes Redestad wrote: > > > I was surprised by the use of SALT in SetN. I'm guessing you could > > improve SetN by adapting the tricky circular array traversal code from > > ArrayDeque. > > I'm not convinced that the extra non-determinism from negative SALT > >

Re: RFR: 8215995: Add specialized toArray methods to immutable collections

Hi Martin, On 2019-01-02 20:00, Martin Buchholz wrote: Looks good to me. thanks! Can you explain why there are two identical test methods get and get2 ? It was to provoke the expected level of mono-, bi- and megamorphicness at each callsite depending on the method under test, while

Re: RFR: 8215995: Add specialized toArray methods to immutable collections

Looks good to me. Can you explain why there are two identical test methods get and get2 ? I was surprised by the use of SALT in SetN. I'm guessing you could improve SetN by adapting the tricky circular array traversal code from ArrayDeque. I'm not convinced that the extra non-determinism from

RFR: 8215995: Add specialized toArray methods to immutable collections

Hi, the Set and List implementations in java.util.ImmutableCollections inherits toArray from AbstractCollection, whose implementations always fall back to an iterator-based approach. Additionally there's logic to deal with not getting the expected number of elements from the iterator, which

RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12

Looking for reviewers to make sure this CSR passes muster. CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 Thank you. Cheers, — Jim

Re: Class.getDeclaredMethods() is returning inherited methods

Hi Steve, What you have observed is an artifact of how Java the language is compiled into bytecode contained in .class files and the fact that Java reflection API returns information about the compiled .class files. The quoted sample code: package x.y; class A {   public void m() {   } }

Class.getDeclaredMethods() is returning inherited methods

I am looking into an issue where the Class.getDeclaredMethods() is returning inherited methods, where the Java Doc here:- https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getDeclaredMethods() states:- "Returns an array containing Method objects reflecting all

Re: RFR 6996807 : FieldReflectorKey hash code computation can be improved

Hi Ivan, Happy New Year! This looks fine. The indentation of line 2311 makes it harder to see all the conditions for the true case. No new webrev needed. Thanks, Roger On 12/31/2018 11:12 PM, Ivan Gerasimov wrote: Gentle ping. I updated the copyright year, as it seems unlikely this

Re: RFR: 8215412: Optimize PrintStream.println methods

Hi Rémi, On 2019-01-02 13:05, Remi Forax wrote: Hi Claes, did you try instead of having a field 'internal' to inline the class check (this.getClass() == PrintStream.class) at every call site you are reading that field ? for a method like println(), the VM has to do a class check (if CHA is

Re: RFR: 8215412: Optimize PrintStream.println methods

Hi Claes, did you try instead of having a field 'internal' to inline the class check (this.getClass() == PrintStream.class) at every call site you are reading that field ? for a method like println(), the VM has to do a class check (if CHA is defeated) before entering the method println so the

Re: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions)

On 21/12/2018 13:43, Langer, Christoph wrote: Hi Alan, Adding support for POSIX file permissions to the zip APIs is problematic as we've been discussing here. There are security concerns and also concerns that how it interacts with JAR files and signed JAR in particular. I don't disagree that

Re: RFR: 8215412: Optimize PrintStream.println methods

Hi, new webrev: http://cr.openjdk.java.net/~redestad/8215412/jdk.02/ - Adds a forgotten String.valueOf in println(String), making sure all methods are semantically the same for - Remove the isInternal method and use only exact match with PrintStream.class to determine whether to use the