Re: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package

On 05/03/2016 01:37 AM, Paul Sandoz wrote: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ Both JDK and HS changes look good to me. It's

Re: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs

Hi Sherman, On 05/03/2016 02:28 AM, Xueming Shen wrote: > Please help review the performance cleanup for zipfs > > issue: https://bugs.openjdk.java.net/browse/JDK-8150496 > webrev: http://cr.openjdk.java.net/~sherman/8150496/webrev ZipFileSystem.java: *) These should be removed? 2032

Re: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes

On 05/02/2016 05:07 PM, Claes Redestad wrote: > I'd like to sponsor this patch proposed by Jaroslav Kameník here: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040660.html > > Bug https://bugs.openjdk.java.net/browse/JDK-8155795 > Webrev:

Re: JDK 9 RFR of adding a few @jls tags to java.lang.String

Hi, Looks good to me! Thanks for taking care of this. -Aleksey On 04/30/2016 10:34 PM, joe darcy wrote: > Hello, > > Please review the small patch below to add some JLS references to the > string class to supplement its textual discussion of a few sections of > the JLS. > > Thanks, > > -Joe

Re: RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures

On 04/30/2016 02:42 AM, Paul Sandoz wrote: >> On 29 Apr 2016, at 15:12, Aleksey Shipilev <aleksey.shipi...@oracle.com> >> wrote: > Looks good. > > Small tweak if you so wish to do so: > > #if[JdkInternalMisc] > static final int WEAK_ATTEMPTS = Integer.ge

RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures

Hi, I would like to fix a simple testbug in our weakCompareAndSet VarHandles and Unsafe intrinsics tests. weakCompareAndSet is spec-ed to allow spurious failures, but current tests do not allow that. This blocks development and testing on non-x86 platforms. Bug:

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

On 04/29/2016 04:38 PM, Claes Redestad wrote: > On 2016-04-29 15:31, Tagir F. Valeev wrote: >> Hello! >> >> Thank you for comments. Update: >> http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r3/ > > Looks good. Okay, good! I'll sponsor. Thanks, -Aleksey

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

On 04/29/2016 03:40 PM, Tagir F. Valeev wrote: > http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r2/ JDK part looks good to me. Test: *) Formatting: "i=0", "i

Re: RFR (XS) 8155090: String concatenation fails with a custom SecurityManager that uses concatenation

On 04/29/2016 10:09 AM, Chris Hegarty wrote: >> On 28 Apr 2016, at 21:54, Claes Redestad > > wrote: >>> The cleanest (yet subtle) solution here is to make sure the default SCF >>> settings are good to run with, which allows transient

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

On 04/29/2016 01:05 PM, David Holmes wrote: > On 29/04/2016 7:50 PM, Aleksey Shipilev wrote: >> On 04/29/2016 02:09 AM, David Holmes wrote: >>> This change is small in nature but somewhat broad in scope. It "affects" >>> the implementation of System.

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

On 04/29/2016 02:09 AM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8154710 > webrev: http://cr.openjdk.java.net/~dholmes/8154710/webrev/ Looks good. Is hrtime_t always integral, so you can "(hrtime_t)now / NANOSECS_PER_MILLISEC" it? > This change is small in nature but

Re: RFR (XS) 8155215: java.lang.String concatenation spec is unnecessarily strong

On 04/27/2016 01:33 PM, Aleksey Shipilev wrote: > Please review this tiny spec improvement that syncs up JLS and > java.lang.String Javadoc. java.lang.String Javadoc unnecessarily locks > down the implementation details for String concat (e.g. usage of > StringBuilde

RFR (XS) 8155090: String concatenation fails with a custom SecurityManager that uses concatenation

Hi, Please review the fix for a shady bootstrapping issue, when a custom SecurityManager is using string concatenation: https://bugs.openjdk.java.net/browse/JDK-8155090 The essence of the issue is that during StringConcatFactory::, we are reading the system properties via the privileged calls.

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

On 04/28/2016 10:37 AM, Tagir F. Valeev wrote: > Hello! > > Please review and sponsor the following patch: > https://bugs.openjdk.java.net/browse/JDK-8155600 > http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r1/ I like the motivation and the patch. Nitpicks: *) Does EA break if you make

Re: RFR(S): 8155106: MHs.Lookup.findConstructor returns handles for array classes

On 04/27/2016 03:38 PM, Michael Haupt wrote: > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8155106 > Webrev: http://cr.openjdk.java.net/~mhaupt/8155106/webrev.00/ Looks okay. -Aleksey

Re: String.equalsIgnoreCase(...) optimization

Hi Andrey, On 04/27/2016 12:57 PM, Andrey wrote: > I publish my JMH benchmark at github > https://github.com/volodin-aa/openjdk-benchmark Please note that you really should compete with JDK 9 String, not with JDK 8. String.equalsIgnoreCase is different in JDK 9, and the obvious improvement one

RFR (XS) 8155215: java.lang.String concatenation spec is unnecessarily strong

Hi, Please review this tiny spec improvement that syncs up JLS and java.lang.String Javadoc. java.lang.String Javadoc unnecessarily locks down the implementation details for String concat (e.g. usage of StringBuilder): http://cr.openjdk.java.net/~shade/8155215/webrev.00/ I'll submit CCC as

Re: [jmm-dev] RFR 8154755: Add a VarHandle weakCompareAndSet with volatile semantics

On 04/21/2016 07:21 PM, Paul Sandoz wrote: > Please review: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154755-weak-cas-volatile/webrev/ Looks okay to me. -Aleksey

Re: RFR 8151198: VarHandle factory-specific exceptions

On 04/08/2016 09:39 PM, Hans Boehm wrote: > I didn't previously have the impression that get/setOpaque was analogous > to just C/C++ volatile. C volatile officially has nothing to do with > threads and does not prevent undefined behavior for data races. It does > not in general guarantee

Re: RFR 8151198: VarHandle factory-specific exceptions

On 04/08/2016 03:51 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/webrev/ > I agree with updates. But have more comments on C/C++ @apiNote-s. Would you like

Re: RFR 8151705 VarHandle.AccessMode enum names should conform to code style

On 04/07/2016 04:39 PM, Paul Sandoz wrote: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/webrev/ Looks good. The performance is OK. -Aleksey

Re: RFR 8151706: Update VarHandle implementation to use @Stable arrays

On 04/08/2016 12:56 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151706-VH-form-table-stable/webrev/ > > > Now that @Stable arrays are supported by C1 (thanks Vladimir!) we > can switch

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

On 04/03/2016 03:51 AM, Claes Redestad wrote: > BufferedInputStream is loaded early, and uses > AtomicReferenceFieldUpdater to provide CAS functionality to allow for > closing streams asynchronously. Using Unsafe directly instead does > the exact same thing in the end, but avoids loading a few

Re: RFR: 8152951: Avoid calculating the reverse of StringConcatFactory$Recipe elements

On 03/29/2016 02:47 PM, Claes Redestad wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8152951 > Webrev: http://cr.openjdk.java.net/~redestad/8152951/webrev.01/ Still good. -Aleksey

Re: RFR [9] 8152642: Remove sun.misc.Unsafe dependency from java.lang.reflect.Proxy

Yes, +1. -Aleksey On 03/24/2016 01:51 PM, Chris Hegarty wrote: > Trivially, looks like a minor oversight that inadvertently introduced a > dependency on sun.misc.Unsafe. > > diff --git a/src/java.base/share/classes/java/lang/reflect/Proxy.java >

Re: RFR (S) 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization

On 03/24/2016 12:19 PM, Chris Hegarty wrote: > On 24 Mar 2016, at 09:15, Peter Levart wrote: >> Looks nice to me, but I'm not a Reviewer. Quite an improvement for longer >> strings. > > +1 Thanks Peter and Chris! Pushed. -Aleksey

Re: RFR (S) 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization

On 03/16/2016 11:13 AM, Aleksey Shipilev wrote: > I'd like to improve our advanced String concat strategy, > MH_INLINE_SIZED_EXACT, with skipping the storage initialization: > https://bugs.openjdk.java.net/browse/JDK-8150463 > > Webrev: > http://cr.openjdk.java.net/~shade

Re: RFR: 8152074: Avoid lambda usage in StringConcatFactory initializer

On 17.03.2016 09:50, Claes Redestad wrote: > please review this patch to remove lambda usage in the > StringConcatFactory initializer, which saves some parts of > java.lang.invoke infrastructure initialization for later. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152074 > Webrev:

Re: RFR: 8152074: Avoid lambda usage in StringConcatFactory initializer

On 17.03.2016 10:10, Claes Redestad wrote: > On 2016-03-17 08:05, Aleksey Shipilev wrote: >> Is there any performance benefit in keeping the single PrivilegedBlock >> though? I.e. convert the lambda to anonymous class, and be done with it? > > I haven't measured it thoroug

RFR (S) 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization

Hi, I'd like to improve our advanced String concat strategy, MH_INLINE_SIZED_EXACT, with skipping the storage initialization: https://bugs.openjdk.java.net/browse/JDK-8150463 Webrev: http://cr.openjdk.java.net/~shade/8150463/webrev.01/ Performance had improved, as planned:

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 03/12/2016 02:49 AM, Coleen Phillimore wrote: > On 3/11/16 6:36 PM, Aleksey Shipilev wrote: >> On 03/08/2016 01:55 AM, Coleen Phillimore wrote: >>>> Aside: see the last experiment, avoiding StringTable::intern (shows in >>>> profiles a lot!) trims down construc

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 03/08/2016 01:55 AM, Coleen Phillimore wrote: >> Aside: see the last experiment, avoiding StringTable::intern (shows in >> profiles a lot!) trims down construction costs down even further. I'd >> think that is a worthwhile improvement to consider. > > Hm, this is an interesting experiment.

Re: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors

On 03/10/2016 08:06 PM, Paul Sandoz wrote: >> On 8 Mar 2016, at 19:27, Paul Sandoz wrote: >> The changes in this webrev take advantage of those for JDK-8149469 and apply the unsafe double addressing scheme so certain byte buffer view implementations can work

Re: RFR: Regex exponential backtracking issue --- more cleanup/tuning

On 03/08/2016 08:45 PM, Xueming Shen wrote: > [2] http://cr.openjdk.java.net/~sherman/regexClosure/MyBenchmark.java Do return the matches() result: @Benchmark public boolean testMethod() { return matcher.reset(input).matches(); } Thanks, -Aleksey

Re: java.net.http.ExecutorWrapper "memory fence"

Alan mentioned I should have sent this to net-dev@. Instead, I submitted a new bug: https://bugs.openjdk.java.net/browse/JDK-8151505 -Aleksey On 03/09/2016 02:06 PM, Aleksey Shipilev wrote: > Hi, > > In recently committed java.net.http.ExecutorWrapper, there is a > synchronize

java.net.http.ExecutorWrapper "memory fence"

Hi, In recently committed java.net.http.ExecutorWrapper, there is a synchronize() method [1], which is used as "memory fence" [2]: public synchronized void synchronize() {} public void execute(Runnable r, Supplier ctxSupplier) { synchronize(); Runnable r1 = () -> { try {

Re: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors

On 03/08/2016 04:06 PM, Paul Sandoz wrote: > Please pre-emptively review a fix to update the buffer implementations to > leverage the Unsafe unaligned accessors: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/ *) My concern with using

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

On 03/08/2016 02:10 PM, Chris Hegarty wrote: > … and the links: > > http://cr.openjdk.java.net/~chegar/8151384/webrev.02/ > http://cr.openjdk.java.net/~chegar/8151384/bench.02/ Looks good. Ship it! -Aleksey

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

Hi Chris, On 03/08/2016 12:55 AM, Chris Hegarty wrote: > Updated links: > http://cr.openjdk.java.net/~chegar/8151384/webrev.01/ *) Your previous patch had the explicit access to CharacterDataLatin1.instance.(toLowerCase|toUpperCase). Any reason not to use it in your new patch? Probably saves

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

Hi, On 03/07/2016 07:29 PM, Chris Hegarty wrote: > What is in the webrev is specialized versions of compare when > the coder of the strings match. Alternatively, this could be pushed > down to String[Latin1|UTF16]. > > Webrev & bug: > http://cr.openjdk.java.net/~chegar/8151384/webrev.00/ >

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 03/02/2016 11:21 PM, Aleksey Shipilev wrote: > On 03/02/2016 10:57 PM, Coleen Phillimore wrote: >> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>> Is there an underlying reason why we can't return the pre-filled >>> StackTraceElements[] array from the JVM_Get

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 03/02/2016 10:57 PM, Coleen Phillimore wrote: > On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >> Is there an underlying reason why we can't return the pre-filled >> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >> with? This will avoid leaking StackTra

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Hi Coleen, On 03/02/2016 09:44 PM, Coleen Phillimore wrote: > Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, > with JVM_GetStackTraceElements that gets all the elements in the > StackTraceElement[] > > These improvements were found during the investigation for replacing >

Re: Frequent allocations / promotions of StringCoding$String{Encoder,Decoder} objects

On 02/25/2016 11:48 PM, Tony Printezis wrote: > Has anyone identified this issue before? Hm, there is a blast from the past: https://bugs.openjdk.java.net/browse/JDK-4806753 In comments there, Mark suggests a patch that apparently handles multiple coders. I wonder where did that go. Also,

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

150180/webrev.jdk.02 (which looks > even better)? > > Thanks! > > /Claes > > On 2016-02-23 11:24, Aleksey Shipilev wrote: >> On 02/19/2016 05:42 PM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/ >>>>

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

On 02/19/2016 05:42 PM, Vladimir Ivanov wrote: >>http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/ >>http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/ > Looks good. A few more reviews, please? Cheers, -Aleksey

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 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

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

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 (S) 8149835: StringConcatFactory should emit classes with the same package as the host class

On 02/17/2016 07:10 PM, Alan Bateman wrote: > > > On 17/02/2016 13:41, Aleksey Shipilev wrote: >> : >> >> Alan, Mandy, would you like to review this as well? This should fix Jake >> compatibility problems. >> >> > Yes, I think this is okay althou

Re: RFR (S) 8149835: StringConcatFactory should emit classes with the same package as the host class

On 02/17/2016 01:48 PM, Paul Sandoz wrote: >> On 17 Feb 2016, at 10:36, Aleksey Shipilev <aleksey.shipi...@oracle.com> >> wrote: >> Yes: >> http://cr.openjdk.java.net/~shade/8149835/webrev.jdk.02/ >> http://cr.openjdk.java.net/~shade/8149835/webrev.lan

Re: RFR (S) 8149835: StringConcatFactory should emit classes with the same package as the host class

On 02/16/2016 11:59 PM, Andrej Golovnin wrote: > Hi Aleksey, > >> http://cr.openjdk.java.net/~shade/8149835/webrev.jdk.01/ > > 701 return (pkg != null ? pkg.getName().replace(".", "/") > + "/" : "") + "Stubs$$StringConcat"; > 702 } else { > 703

RFR (S) 8149835: StringConcatFactory should emit classes with the same package as the host class

Hi, Please review a StringConcatFactory fix that makes generated String concat stubs to be named "$$StringConcat/", instead of "java/lang/String$$Concat/": https://bugs.openjdk.java.net/browse/JDK-8149835 Among other things, this helps to dodge the failure caught by stricter access controls in

Re: JDK 9 RFR of JDK-8149896: Remove unnecessary values in FloatConsts and DoubleConsts

On 02/16/2016 09:23 AM, joe darcy wrote: > Please review the webrev > > http://cr.openjdk.java.net/~darcy/8149896.0/ +1, nice cleanup. -Aleksey (not a Reviewer)

Re: [9] RFR (XS): 8148518: Unsafe.getCharUnaligned() loads aren't folded in case of -XX:-UseUnalignedAccesses

On 02/15/2016 10:01 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8148518/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8148518 +1 > Current Unsafe::getCharUnaligned Java implementation isn't fully > optimized by C2: it never constant folds such loads from char

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 10.02.2016 17:07, Chris Hegarty wrote: > Thanks Aleksey, your proposal is better. So the complete change is: > > diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java > b/src/java.base/share/classes/java/io/ObjectInputStream.java > ---

Re: RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

Thanks guys, pushed. -Aleksey On 10.02.2016 16:19, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 2/10/16 3:51 PM, Aleksey Shipilev wrote: >> See new webrev that adds a few more tests: >> http://cr.openjdk.jav

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 10.02.2016 16:51, Chris Hegarty wrote: > On 08/02/16 21:54, Aleksey Shipilev wrote: >> ... >> Still, the corrupted stream may call readUTFBody(1L + >> Integer.MAX_VALUE), that yields initial capacity of -2147483648, which >> in turn fails StringBuilder(...) with

RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

Hi, I would like to make StringConcatFactory more coherent with existing LambdaMetafactory: https://bugs.openjdk.java.net/browse/JDK-8149459 http://cr.openjdk.java.net/~shade/8149459/webrev.01/ Testing: jdk/test/java/String/concat jtreg, JPRT Cheers, -Aleksey

Re: RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

See new webrev that adds a few more tests: http://cr.openjdk.java.net/~shade/8149459/webrev.02/ On 10.02.2016 14:25, Remi Forax wrote: > Hi Aleksey, if you have a dumper, you should append a value at the > end of the generated class otherwise if you have more than one string > concatenation, you

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 09.02.2016 00:40, Chris Hegarty wrote: > And of course, this should read... > > >> On 8 Feb 2016, at 15:34, Chris Hegarty wrote: >> >> It was suggested to me off-list that the implementation should choose a >> reasonable initial capacity value ,to size the

Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

48, 4, buf, 19, 4); > I would suggest using unsigned shift >>> here just to avoid thinking > about whether the sign matters or not. > Not a big deal, of course. > > 2) > Do you want to add the bug id 8148936 to the @bug list in the regression > test? > > Sincerely

Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Thanks guys, pushed. Now, on to StringJoiner... -Aleksey On 02/04/2016 03:10 PM, Ivan Gerasimov wrote: > Looks even better, thanks! > > Sincerely yours, > Ivan > > On 04.02.2016 14:54, Aleksey Shipilev wrote: >> Sure, here's a new webrev: >>http://cr.openjdk.

Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

On 02/04/2016 04:29 PM, Florent Guillaume wrote: > Looking at the webrev it seems that the Javadoc for > Long.formatUnsignedLong has not been removed. There are two following methods that are related to that Javadoc. But I agree, these should be cleaned up along with other *Latin1/*UTF16 methods

RFR (XS) (urgent) 8149044: jdk/internal/misc/JavaLangAccess/FormatUnsigned.java fails all platforms

Hi, jdk/internal/misc/JavaLangAccess/FormatUnsigned.java started failing after UUID.toString() optimizations purged the methods from JavaLangAccess: https://bugs.openjdk.java.net/browse/JDK-8149044 My bad, I should have ran JavaLangAccess tests after the original change. The fix is to remove

Re: RFR (XS) (urgent) 8149044: jdk/internal/misc/JavaLangAccess/FormatUnsigned.java fails all platforms

Thanks for a quick review, Joe! Pushed. -Aleksey On 02/04/2016 09:32 PM, joe darcy wrote: > HI Aleksey, > > Looks fine. I assume any remaining JavaLangAccess have other tests :-) > > Thanks, > > -Joe > > On 2/4/2016 10:29 AM, Aleksey Shipilev wrote: >

Re: RFR(XS) 8148785: Update class file version to 53 for JDK-9

On 02/03/2016 04:16 PM, harold seigel wrote: > Open webrevs: > http://cr.openjdk.java.net/~hseigel/bug_8148785.jdk/ > http://cr.openjdk.java.net/~hseigel/bug_8148785.hs/ +1 > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8148785 Description seems to imply we change the compiled

RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Hi, JDK-8006627 did the JavaLangAccess hack to improve UUID.toString() performance: public String toString() { char[] chars = new char[36]; jla.formatUnsignedLong(mostSigBits >> 32, 4, chars, 0, 8); chars[8] = '-'; jla.formatUnsignedLong(mostSigBits >> 16, 4,

RFR (S) 8148869: StringConcatFactory MH_INLINE_SIZED_EXACT strategy does not work with -XX:-CompactStrings

Hi, Please review another simple fix in String concat: https://bugs.openjdk.java.net/browse/JDK-8148869 The failure happens because MH_INLINE_SIZED_EXACT strategy has to figure out the coder for the String concat result, as the binary "or" of initial coder and all argument's (possible) coders.

Re: RFR (S) 8148869: StringConcatFactory MH_INLINE_SIZED_EXACT strategy does not work with -XX:-CompactStrings

Thanks guys, pushed. -Aleksey On 02/02/2016 11:07 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > >> On 2 февр. 2016 г., at 22:41, Aleksey Shipilev <aleksey.shipi...@oracle.com> >> wrote: >> >> Hi, >> &

Re: RFR (S) 8148787: StringConcatFactory exactness check produces bad bytecode when a non-arg concat is requested

On 02/02/2016 05:57 PM, Paul Sandoz wrote: >> On 2 Feb 2016, at 07:00, Aleksey Shipilev <aleksey.shipi...@oracle.com> >> wrote: >> Anyone? This looks like a trivial fix. > > +1. The comment on stack logic is really helpful. Thank you, Vladimir and Paul, pushed. Cheers, -Aleksey

Re: RFR (S) 8148787: StringConcatFactory exactness check produces bad bytecode when a non-arg concat is requested

t regards, > Vladimir Ivanov > > On 2/2/16 10:00 AM, Aleksey Shipilev wrote: >> Anyone? This looks like a trivial fix. >> >> -Aleksey >> >> On 02/01/2016 10:47 PM, Aleksey Shipilev wrote: >>> Hi, >>> >>> Please review the fix for a cor

RFR (XS) 8148730: Add @since tags in new String concat APIs

Hi, Please review this tiny update, that puts @since 9 tags over new Indify String Concat JDK APIs: http://cr.openjdk.java.net/~shade/8148730/webrev.01/ Cheers, -Aleksey

Re: RFR (XS) 8148730: Add @since tags in new String concat APIs

On 02/01/2016 12:44 PM, Andrej Golovnin wrote: >> I don't know, you tell me -- you have the tools that enforce >> @since-ness! Certainly, we can put @since on classes only, if that is >> acceptable. > > I don't have such tools. Apologies, I confused you with another Andrey :) Sure, let's do

Re: RFR (XS) 8148730: Add @since tags in new String concat APIs

ag to the > methods/constructors when the whole class is since JDK 9? As far as I > know the @since tag should be only added to class members introduced > in a later version than the class. > > Best regards, > Andrej Golovnin > > On Mon, Feb 1, 2016 at 10:21 AM, Aleksey Shipilev &

Re: RFR (XS) 8148730: Add @since tags in new String concat APIs

On 02/01/2016 01:03 PM, Alan Bateman wrote: > On 01/02/2016 09:56, Aleksey Shipilev wrote: >> : >> >> Sure, let's do class-only: >>http://cr.openjdk.java.net/~shade/8148730/webrev.02/ >> > Looks good. Thanks guys, pushed. -Aleksey

Re: RFR (S) 8148787: StringConcatFactory exactness check produces bad bytecode when a non-arg concat is requested

Anyone? This looks like a trivial fix. -Aleksey On 02/01/2016 10:47 PM, Aleksey Shipilev wrote: > Hi, > > Please review the fix for a corner case in StringConcatFactory exactness > check, which produces invalid bytecode: > https://bugs.openjdk.java.net/browse/JDK-81

RFR (L) JEP 280: Indify String Concatenation (integration)

Hi again, This is a formal pre-integration review thread for JEP 280 ("Indify String Concatenation") integration: http://openjdk.java.net/jeps/280 The JEP is Targeted, the CCC is approved, the code reviews and pre-integration checks are clean. Code changes are happening simultaneously in

JEP 280 (Indify String Concat) integration

Hi, I think it is time to integrate JEP 280 ("Indify String Concat") into JDK 9: http://openjdk.java.net/jeps/280 The JEP is Targeted, the CCC is approved, the code reviews and pre-integration checks come clean. In theory, we would like to integrate with some "optimal" concat strategy switched

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 01/22/2016 02:34 PM, Claes Redestad wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8148044 > Webrev: http://cr.openjdk.java.net/~redestad/8148044/webrev.01/ -1, sorry. I would actually suggest keeping the ZERO_ARRAY in Enum*, because enums often have small cardinality, and there

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

On 01/22/2016 03:19 PM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8148044/webrev.02/ This one's good. -Aleksey

Re: API review of VarHandles

On 01/22/2016 03:08 PM, Vitaly Davidovich wrote: > The VarHandle API isn't ergonomic like Unsafe; this being for power users > is irrelevant to the ergonomics of the API. Instead, it's fairly verbose > with setup ceremony. Now, I personally don't mind that too much and more > interested in the

Re: API review of VarHandles

On 01/22/2016 04:54 PM, David M. Lloyd wrote: > The costs are both performance and memory overhead. The > Atomic*FieldUpdaters are good for memory usage and reasonably usable, > but suffer from performance problems and generics issues. Hopefully, not anymore:

Re: JEP 280 (Indify String Concat) integration

On 01/22/2016 05:44 PM, Peter Levart wrote: > If StringConcatException ever gets thrown, will it propagate out of the > concatenation expression execution? If yes, then it should probably be > an unchecked exception, right? StringConcatException is modeled after LambdaConversionException: it

Re: use of Unsafe for ASCII detection

On 01/07/2016 02:21 AM, Martin Buchholz wrote: > A stupid benchmark (sorry Aleksey - maybe you already have a jmh > version of this?) http://cr.openjdk.java.net/~martin/Utf8Bench.java Okay, I'll bite: http://cr.openjdk.java.net/~shade/scratch/UTF8Scan.java As Andrew already pointed out, the

Re: Remove sun.misc.CompoundEnumeration

On 12/22/2015 05:57 PM, Chris Hegarty wrote: > http://cr.openjdk.java.net/~chegar/8146000/ Looks good. Thanks, -Aleksey P.S. Nice bug ID, pity to waste it on a trivial thing :D

Re: RFR: 8145862: Improve lazy initialization of fields in java.net.URI

On 12/22/2015 07:13 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8145862/webrev.01 Looks good. Thanks, -Aleksey

Re: Remove sun.misc.CompoundEnumeration

On 12/22/2015 05:41 PM, Chris Hegarty wrote: > sun.misc.CompoundEnumeration is a utility class that supports enumerating > over an array of enumerations. It is used in just a single place in the JDK, > in > ClassLoader.getResources(String) to support enumerating over the parent’s > resources as

Re: RFR(S): 8145988: Use the raw methods of java.net.URI when possible

On 12/22/2015 04:40 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8145988/webrev.01 Looks good. Thanks, -Aleksey

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

On 12/19/2015 04:07 PM, Claes Redestad wrote: > When meticulously going through and checking each usage for odd pattern > like this I accidentally did a bit of extra cleanup, mostly addressing a > number of cases where the volatile field was being read twice. Sorry! > > Bug:

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

On 12/21/2015 12:46 PM, Andrew Haley wrote: >> See: "Speed-kings of inverting booleans" at >> http://www.javaspecialists.eu/archive/Issue042.html > > That's from 2002, and not valid any more. Maybe not valid even back > then. It is not valid today, I've checked a while ago:

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

Hi Peter, On 12/17/2015 03:19 PM, Peter Levart wrote: > Wouldn't that change make a possible outcome of keySet() returning null > in case it was invoked concurrently? Wouldn't you have to use a local > variable to prevent that? Ah yes! Silly me. I remember looking at most usages and seeing that

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

On 12/17/2015 04:54 PM, Ulf Zibis wrote: > Am 17.12.2015 um 08:54 schrieb Aleksey Shipilev: >> On 12/17/2015 02:34 AM, Ulf wrote: >>> I'm wondering why moving the increment operation to an extra line wound >>> enhance performance. >> Because C1 is very straig

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

On 12/17/2015 06:07 PM, Doug Lea wrote: > On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: >> Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as >> package-private volatile fields. Their only use is to cache keySet and >> valueSet implementations from

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

2015 05:55 PM, Roger Riggs wrote: > Hi Alexsey, > > The 'expected to run benchmarks' might the operative comment in the code. > 'Common' knowledge sometimes isn't so common. > > Roger > > > On 12/17/2015 2:54 AM, Aleksey Shipilev wrote: >> On 12/17/2015 02:34

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

On 12/17/2015 08:18 PM, Paul Sandoz wrote: > >> On 17 Dec 2015, at 17:54, Roger Riggs wrote: >> >> I agree that you should just push it and move on. >> > > +1 Thanks Claes, Sherman, Roger, and Paul! Pushed. Cheers, -Aleksey

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

On 12/17/2015 08:21 PM, Paul Sandoz wrote: >> On 17 Dec 2015, at 16:54, Aleksey Shipilev <aleksey.shipi...@oracle.com> >> wrote: >> On 12/17/2015 06:07 PM, Doug Lea wrote: >>> On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: >>>> Since the dawn o

RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

Hi, I would like to suggest a simple cleanup/improvement in current StringUTF16, which somewhat closes the gap between C1 and C2 performance with Compact Strings: https://bugs.openjdk.java.net/browse/JDK-8145428 http://cr.openjdk.java.net/~shade/8145428/webrev.02/ It does improve the score

<    2   3   4   5   6   7   8   9   10   11   >