Re: RFR: 8222852: Reduce String concat combinator tree shapes by folding constants into prependers

Hi Peter, On 2019-04-28 23:34, Claes Redestad wrote: What do you think? This is what I meant by "simplified wiring logic": http://cr.openjdk.java.net/~plevart/jdk-dev/8222852_StringConcatOpt/webrev.02p/ I haven't tried this though, but if it works correctly and if JIT inlines the strate

Re: RFR: JDK-8222930: ConcurrentSkipListMapTest.clone() broken since jdk10

Hi All, Reviews and feedback requested for the fix. http://cr.openjdk.java.net/~afarley/8222930.1/jdk13/webrev Martin: Thanks for the testcase. I've replaced the old test in the webrev with your generalized one. :) Best Regards Adam Farley IBM Runtimes Adam Farley8/UK/IBM wrote on 25/04/2

Re: RFR: 8222852: Reduce String concat combinator tree shapes by folding constants into prependers

That's nice ! In StringConcatFactory, i will change prefixConstant + constantValue (resp suffixConstant + constantValue) to prefixConstant.concat(constantValue) to not depend on any string concat implementations of javac. regards, Rémi - Mail original - > De: "Claes Redestad" > À:

Re: RFR: 8222852: Reduce String concat combinator tree shapes by folding constants into prependers

Hi Rémi, On 2019-04-29 13:36, Remi Forax wrote: That's nice ! thanks for reviewing! In StringConcatFactory, i will change prefixConstant + constantValue (resp suffixConstant + constantValue) to prefixConstant.concat(constantValue) to not depend on any string concat implementations of

Re: RFR: 8222852: Reduce String concat combinator tree shapes by folding constants into prependers

- Mail original - > De: "Claes Redestad" > À: "Remi Forax" > Cc: "Peter Levart" , "Aleksey Shipilev" > , "core-libs-dev" > > Envoyé: Lundi 29 Avril 2019 16:57:45 > Objet: Re: RFR: 8222852: Reduce String concat combinator tree shapes by > folding constants into prependers > Hi Rémi,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hello, We did review build changes as they were done in the sandbox, but IMO this change needs a fresh review now since some things have changed in the build since those reviews took place. CompileJavaModules.gmk: The -parameters flag to javac is currently only used for jdk.aot and jdk.inte

RFR: 8223078: Add microbenchmark for array copying/clearing/resizing

8223078: Add microbenchmark for array copying/clearing/resizing https://cr.openjdk.java.net/~martin/webrevs/jdk/ArrayFiddle-jmh/ https://bugs.openjdk.java.net/browse/JDK-8223078

Re: RFR: 8223078: Add microbenchmark for array copying/clearing/resizing

On 4/29/19 12:39 PM, Martin Buchholz wrote: > 8223078: Add microbenchmark for array copying/clearing/resizing > https://cr.openjdk.java.net/~martin/webrevs/jdk/ArrayFiddle-jmh/ > https://bugs.openjdk.java.net/browse/JDK-8223078 > Looks good, although even more informative would be to try some dif

Re: RFR: 8223078: Add microbenchmark for array copying/clearing/resizing

On Mon, Apr 29, 2019 at 9:49 AM Doug Lea wrote: > On 4/29/19 12:39 PM, Martin Buchholz wrote: > > 8223078: Add microbenchmark for array copying/clearing/resizing > > https://cr.openjdk.java.net/~martin/webrevs/jdk/ArrayFiddle-jmh/ > > https://bugs.openjdk.java.net/browse/JDK-8223078 > > > > Looks

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 4/29/2019 12:21 PM, Erik Joelsson wrote: There is a new set of macros that should be used to check things like target OS. The new macro is called like this: ifeq ($(call isTargetOs, windows macosx linux), false) Lib-jdk.jpackage.gmk and Launcher-jdk.jpackage.gmk: Same thing with checkin

RFR: jsr166 integration 2019-05

https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8222930: ConcurrentSkipListMap.clone() shares size variable between original and clone https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ConcurrentSkipListMap.clone/index.html https://bugs.openjdk.jav

Re: RFR: JDK-8219483: j.l.c.ClassDesc::nested(String, String...) doesn't throw NPE if any arg is null

Hi Joe, Thanks for the review. I have modified the patch, please see [1] . I still need a reviewer for the CSR [2], Vicente [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8223034 On 4/26/19 9:32 PM, Joe Darcy wrote: Hi Vicente, For

Re: RFR: 8223078: Add microbenchmark for array copying/clearing/resizing

On 2019-04-29 19:03, Martin Buchholz wrote: On Mon, Apr 29, 2019 at 9:49 AM Doug Lea > wrote: On 4/29/19 12:39 PM, Martin Buchholz wrote: > 8223078: Add microbenchmark for array copying/clearing/resizing > https://cr.openjdk.java.net/~martin/webrevs/

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

jpackage reviewers: We hope to move JEP 343 to "Proposed to Target" next week, so we would like expedite the review process as much as possible. The total change is huge, so I am including the below descriptions of some of the central and important classes included: jdk.jpackage.main.Main:

RFR(JDK 13/java.xml) 8222991: Xerces 2.12.0: Validation

Please review an update on the Validation implementation. All XML tests and JCK passed. JBS: https://bugs.openjdk.java.net/browse/JDK-8222991 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8222991/webrev/ Thanks, Joe

Re: RFR 8222955 : Optimize String.replace(CharSequence, CharSequence) for Latin1 encoded strings

Thank you Tagir for suggestion! On 4/26/19 1:24 AM, Tagir Valeev wrote: Hello! Great optimization! +// overflow-conscious code +int resultLen = valLen + (++p) * deltaLen; +if (Integer.MAX_VALUE / p < deltaLen || +Integer.MAX_VALUE - resultLen < 0) { +

Re: RFR 8222955 : Optimize String.replace(CharSequence, CharSequence) for Latin1 encoded strings

Hi Claes! On 4/25/19 4:51 AM, Claes Redestad wrote: Hi Ivan, the changes and fast-path speed-ups look reasonable, but I'd like to see that the overhead for cases not helped by the fast paths isn't excessive, e.g., micro variants with UTF16 Strings and a mix of Latin1 and UTF16. Good point! A

Re: RFR 8222955 : Optimize String.replace(CharSequence, CharSequence) for Latin1 encoded strings

Hello everyone! Please help review the second version of the enhancement. A separate branch was added to handle UTF16 in the searched string and/or in the target and replacement. Switching to Math.xxxExact() suggested by Tagir gave ~4% of throughput on affected test cases. Also, allocating