Re: RFR: JDK-8225056 VM support for sealed classes

Hi David, On 5/19/20 19:31, David Holmes wrote: Hi Serguei, On 20/05/2020 1:49 am, serguei.spit...@oracle.com wrote: Hi Harold and David, Just one comment. We could save on the CSR's for:    make/data/jdwp/jdwp.spec || src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java ||

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Serguei, On 20/05/2020 1:49 am, serguei.spit...@oracle.com wrote: Hi Harold and David, Just one comment. We could save on the CSR's for:   make/data/jdwp/jdwp.spec || src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java ||

Re: Update Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

As I wrote to openjdk alias tier3 seems to be more reasonable tier for incubating feature tests. Once the tests will be integrated we will also need to add these tests into hs-comp tiers to be tested with additional compiler flags (like -Xcomp). -katya On 5/19/20 3:25 PM, Paul Sandoz wrote:

Re: Update Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

I just realized that the vector tests have not been included in any JDK test category e.g. tier1. Ordinarily I would expect the tests to be added to tier1 since the tests exercise intrinsics. However, those intrinsics are only enabled with the Vector API module so we could place in another

Re: RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted

Thank you Paul.  > On May 19, 2020, at 5:41 PM, Paul Sandoz wrote: > > +1 > Paul. > >> On May 19, 2020, at 1:00 PM, Jim Laskey wrote: >> >> Please review this change to remove the preview heading from the javadoc of >> String::formatted. This also updates the @since to 15. >> >> Thank

Re: RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted

+1 Paul. > On May 19, 2020, at 1:00 PM, Jim Laskey wrote: > > Please review this change to remove the preview heading from the javadoc of > String::formatted. This also updates the @since to 15. > > Thank you. > > Cheers, > > -- Jim > > > csr:

Re: Optimize (Linked-)HashMap lookup when backing array is null

Hi, Right, its only in the case of removing the node because the new value was null. Besides being infrequent, that should not be a problem. Thanks, Roger On 5/19/20 3:56 PM, Christoph Dreis wrote: Hi Roger, How does the performance degrade when the computation of the hash is

RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted

Please review this change to remove the preview heading from the javadoc of String::formatted. This also updates the @since to 15. Thank you. Cheers, -- Jim csr: https://bugs.openjdk.java.net/browse/JDK-8245399 jbs:

Re: Optimize (Linked-)HashMap lookup when backing array is null

Hi Roger, > How does the performance degrade when the computation of the hash > is non-trivial. For example, with an array as a key or an object with > fields that are objects? > The original code made a point of computing the hash only once. HashMap.get() and HashMap.containsKey() etc. would

Re: Optimize (Linked-)HashMap lookup when backing array is null

Hi, How does the performance degrade when the computation of the hash is non-trivial. For example, with an array as a key or an object with fields that are objects? The original code made a point of computing the hash only once. ??, Roger On 5/19/20 3:21 PM, Claes Redestad wrote: Thanks

Re: RFR: 8215401: Add isEmpty default method to CharSequence

Hi Jason, I guess overriding and marking the CharBuffer method final for consistency wouldn't hurt. Except I probably need to pass this through another CSR review. Also added test cases for char[] and String-based CharBuffers: http://cr.openjdk.java.net/~redestad/8215401/open.01/ /Claes On

Re: Optimize (Linked-)HashMap lookup when backing array is null

Thanks for producing the simpler variant and getting some comparative runs done. On 2020-05-19 19:50, Christoph Dreis wrote: I would probably go for the first version although it is a bit more complicated and has the computeIfPresent caveat, because it doesn't slow down the common Map.get()

Re: Fix for warning related to stream api call chains in java.base

Hi All, Forgot to mention these are IDE warnings I am trying to fix, need a sponsor for this. Regards, Vipin > On May 3, 2020, at 8:40 PM, Vipin Sharma wrote: > > Hi All, > > I have fixed some warnings in java.base module, following are 3 type of code > changes in this patch: > > !

Re: RFR: 8215401: Add isEmpty default method to CharSequence

Claes, I would think CharBuffer would require some testing in your test cases too. Also it looks like some of the CharSequence methods in CharBuffer are declared final. Not sure what is appropriate here as far as CharBuffer::isEmpty modifiers are concerned. Jason

Re: RFR: JDK-8225056 VM support for sealed classes

On 5/19/20 09:46, Harold Seigel wrote: That sounds good! Thanks, Harold On 5/19/2020 11:53 AM, serguei.spit...@oracle.com wrote: Hi Harold, The Serviceability part including the tests looks good to me. I can file a JVMTI enhancement on the jvmtiRedefineClasses.cpp refactoring if you are

Re: Optimize (Linked-)HashMap lookup when backing array is null

Hi Claes, On 2020-05-19 15:15, Christoph Dreis wrote: >> Hi Claes, >> >>> unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty >>> accessors - could this be used to simplify your patch? >> >> I was wondering about that during implementation, but simply took the path I >>

Re: RFR: 8215401: Add isEmpty default method to CharSequence

Hi Claes, Looks good, Thanks for the test. p.s.  I probably would have used a data provider for the CS cases but its not significant. On 5/19/20 6:37 AM, Claes Redestad wrote: Hi Roger, sure, added Emptiness.java with a few sanity tests. /Claes On 2020-05-19 00:29, Roger Riggs wrote: Hi

Re: RFR: JDK-8225056 VM support for sealed classes

That sounds good! Thanks, Harold On 5/19/2020 11:53 AM, serguei.spit...@oracle.com wrote: Hi Harold, The Serviceability part including the tests looks good to me. I can file a JVMTI enhancement on the jvmtiRedefineClasses.cpp refactoring if you are okay with it. Thanks, Serguei On

Re: RFR: JDK-8225056 VM support for sealed classes

I think that's a good idea. Thanks, Harold On 5/19/2020 11:49 AM, serguei.spit...@oracle.com wrote: Hi Harold and David, Just one comment. We could save on the CSR's for:   make/data/jdwp/jdwp.spec || src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java ||

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Harold, The Serviceability part including the tests looks good to me. I can file a JVMTI enhancement on the jvmtiRedefineClasses.cpp refactoring if you are okay with it. Thanks, Serguei On 5/18/20 22:26, David Holmes wrote: Hi Harold, Adding serviceability-dev for the serviceability

Re: RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback

On 2020-05-19 17:22, Paul Sandoz wrote: +1 Thanks! Originally I thought this was a lost cause or too much effort given the edge case, but your prior fix and Peter’s nudging to “lazy” static values made it more viable. Yeah, I had written it off as a lost cause too until Peter nudged me

Re: RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback

+1 Originally I thought this was a lost cause or too much effort given the edge case, but your prior fix and Peter’s nudging to “lazy” static values made it more viable. I agree with not changing the other strategies. Let's remove ‘em. Paul. > On May 19, 2020, at 6:59 AM, Claes Redestad

Re: RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback

Thanks for reviewing, Jim! /Claes On 2020-05-19 16:05, Jim Laskey wrote: +1 On May 19, 2020, at 10:59 AM, Claes Redestad wrote: Hi, while hard to reproduce, it's possible to break the StringConcatFactory if trying to bootstrap a concatenation when the VM is in such a state that any

Re: RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback

+1 > On May 19, 2020, at 10:59 AM, Claes Redestad > wrote: > > Hi, > > while hard to reproduce, it's possible to break the StringConcatFactory > if trying to bootstrap a concatenation when the VM is in such a state > that any allocation will throw an OOME > > By eagerly initializing the

RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback

Hi, while hard to reproduce, it's possible to break the StringConcatFactory if trying to bootstrap a concatenation when the VM is in such a state that any allocation will throw an OOME By eagerly initializing the default strategy classes during bootstrap, while lazily initializing any method

Re: Optimize (Linked-)HashMap lookup when backing array is null

Hi, On 2020-05-19 15:15, Christoph Dreis wrote: Hi Claes, unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty accessors - could this be used to simplify your patch? I was wondering about that during implementation, but simply took the path I already chose for the CHM.

Re: Optimize (Linked-)HashMap lookup when backing array is null

Hi Claes, > unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty > accessors - could this be used to simplify your patch? I was wondering about that during implementation, but simply took the path I already chose for the CHM. > So I'd like to see some analysis on

Re: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes

> On 19 May 2020, at 13:44, Jan Lahoda wrote: > > Hi Vicente, > > javac changes look overall OK to me. > > A few comments: > -the handling of non-sealed in JavacParser is fairly good, even though I > wonder if handling it in the tokenizer would not be better. If I read the > specification

Re: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes

Hi Vicente, javac changes look overall OK to me. A few comments: -the handling of non-sealed in JavacParser is fairly good, even though I wonder if handling it in the tokenizer would not be better. If I read the specification correctly, "non-sealed" is specified as a keyword, so the

Re: Optimize (Linked-)HashMap lookup when backing array is null

Hi Christoph, unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty accessors - could this be used to simplify your patch? It's easy to get heavily biased results in microbenchmarks when all you do is repeatedly calling down one path. That is, JIT might speculatively assume all

Optimize (Linked-)HashMap lookup when backing array is null

Hi, similar to JDK-8244960[1] that I reported last week, I noticed that HashMap & LinkedHashMap could benefit from a similar improvement. I used the following benchmark again to validate the results: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class

RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

Hi, Following up on review requests of API [0], Java implementation and test [1], General Hotspot changes[2] for Vector API and x86 backend changes [3]. Here's a request for review of AArch64 backend changes required for supporting the Vector API: JEP: https://openjdk.java.net/jeps/338 JBS:

Re: RFR: 8215401: Add isEmpty default method to CharSequence

Hi Roger, sure, added Emptiness.java with a few sanity tests. /Claes On 2020-05-19 00:29, Roger Riggs wrote: Hi Claes, Though it does not look like it could be any simpler, there should probably be a test. Checking consistency with the existing implementations of CharSequence.length() and

Re: RFR: 8215401: Add isEmpty default method to CharSequence

Good eye - I believe I intended this to be a {@code} block. Updated in- place. /Claes On 2020-05-19 02:31, Jonathan Gibbons wrote: You might want to check the /generated/ API docs. It doesn't look like the first {@link} will do what you might be expecting. -- Jon On 5/18/20 1:48 PM, Claes

Re: RFR: JDK-8225056 VM support for sealed classes

- Mail original - > De: "David Holmes" > À: "Harold David Seigel" , "hotspot-runtime-dev" > , > "amber-dev" , "core-libs-dev" > , "serviceability-dev" > > Envoyé: Mardi 19 Mai 2020 07:26:38 > Objet: Re: RFR: JDK-8225056 VM support for sealed classes > Hi Harold, > > Adding