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

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

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 straightforward, and code movement like that is a poor man's instruction scheduling, that pads out the data dependency between index update and ind

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

Hi, 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 java.util collections. However, all relevant java.util collections are not having any declared fields (an opaque refere

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 on

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Yes, thanks for more polishing, I have uploaded the updates to: http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.06/ http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.04/ More reviews, please! Thanks, -Aleksey On 11/30/2015 12:34 PM, Andrej Golovnin wrote: > Hi Aleksey, > >> ht

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Maurizio, Updated webrevs: http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.04/ http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.05/ On 11/27/2015 10:13 PM, Maurizio Cimadamore wrote: > Looks great - the only minor quibble is that now StringConcat looks like > a regular javac

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Thanks again, I'll upload the webrevs after further langtools cleanup. On 11/28/2015 12:05 PM, Andrej Golovnin wrote: >>> http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.04/ > > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java > > 356 ARG, > > The comma is n

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Andrej, On 11/27/2015 03:29 PM, Andrej Golovnin wrote: >> http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.03/ > > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java > > The inner class Key is final. But the inner classes Recipe and > RecipeElement are not final. Why?

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Maurizio, Updated webrevs: http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.03/ http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.04/ On 11/27/2015 04:03 AM, Maurizio Cimadamore wrote: > Thanks! The patch looks better, and having the code all in one place > definitively helps. I

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Ivan, Thanks for the reviews. Again, I will publish the updated webrevs after rewiring for Maurizio's comments. On 11/27/2015 02:33 PM, Ivan Gerasimov wrote: > 1) As you touch Long.java anyway, could you change > 508 while (i <= Integer.MIN_VALUE) { > to > 508 while (i < Integ

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi, Again, I'll post the updates after addressing another round of Maurizio's comments :) On 11/27/2015 10:47 AM, Andrej Golovnin wrote: >> http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.02/ > > test/tools/javac/T5024091/T5024091.java > src/jdk.compiler/share/classes/com/sun/tools/

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Maurizio, Thanks for the reviews! Updated webrevs: http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.02/ http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.03/ On 11/26/2015 02:40 PM, Maurizio Cimadamore wrote: > types.boxedClass(syms.voidType).type; > > Note that j.l.Void is

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

On 11/26/2015 12:55 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/ Both JDK and Hotspot changes look good to me. > https://bugs.openjdk.java.net/browse/JDK-8143628 C1 L

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Andrej, Thanks for the review, I'll send the updated webrevs once I address Maurizio's review comments. On 11/26/2015 11:42 AM, Andrej Golovnin wrote: >> http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.02/ > > src/java.base/share/classes/java/lang/Integer.java > src/java.base/share/clas

Re: Code (Pre-)Review for JEP 280: Indify String Concat

On 11/25/2015 03:07 AM, Claes Redestad wrote: > Some variants might be non-existent in a majority of programs, others > might not be needed early on, which could help reduce the footprint a bit. Thanks, indeed, it is savvy to make the MH resolution lazier. See the update: http://cr.openjdk.java

Re: RFR 6856817: Poor performance of Writer#append with CharBuffer

On 11/25/2015 06:22 PM, Aleksey Shipilev wrote: > On 11/25/2015 05:29 PM, vyom wrote: >> Please review my changes for below bug. >> >> Bug:JDK-6856817 : Poor performance of Writer#append with CharBuffer >> Webrev: http://cr.openjdk.java.net/~vtewari/6856817/

Re: RFR 6856817: Poor performance of Writer#append with CharBuffer

Hi vyom, On 11/25/2015 05:29 PM, vyom wrote: > Hi All, > > Please review my changes for below bug. > > Bug:JDK-6856817 : Poor performance of Writer#append with CharBuffer > Webrev: http://cr.openjdk.java.net/~vtewari/6856817/webrev0.4/ Interesting change. But, I think the "null" handli

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 11/25/2015 06:14 PM, Claes Redestad wrote: > On 2015-11-25 16:06, Aleksey Shipilev wrote: >> On 11/25/2015 05:44 PM, Claes Redestad wrote: >> Nit: don't you want to inline BD.getTypeChar into BD.unparseSig to avoid >> "c != 'L')" comparison?

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 11/25/2015 05:44 PM, Claes Redestad wrote: > please review this small cleanup/startup improvement which defers a few > classes from loading during startup and consolidates some static utility > methods to generate type signatures: > > webrev: http://cr.openjdk.java.net/~redestad/8143926/webrev.

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 07:50 PM, Ulf wrote: > Am 24.11.2015 um 12:07 schrieb Aleksey Shipilev: >> Thanks for reviews, Ivan, John, Sherman and Paul! >> >> I am pushing this change now. > > I know, I'm late, but have you ever tried? : No, but you can try it yourself. Open

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Paul, Thanks for the review! Updated webrevs: http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.01/ http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.01/ More reviews, please :) Comments below: On 11/24/2015 05:16 PM, Paul Sandoz wrote: >> On 19 Nov 2015, at 21:58, A

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 05:20 PM, Paul Sandoz wrote: >> On 24 Nov 2015, at 15:17, Aleksey Shipilev >> wrote: >> Oh no, I don't. Pre-integration JPRT runs exposed an opaque dependency >> on Integer.sizeTable field from C2 OptimizeStringConcat. I added the >&

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 02:07 PM, Aleksey Shipilev wrote: > On 11/24/2015 03:35 AM, John Rose wrote: >> On Nov 23, 2015, at 1:42 PM, Aleksey Shipilev >> mailto:aleksey.shipi...@oracle.com>> wrote: >>> >>> Okay, here it is (only tests changed): >>> htt

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Hi Stuart, On 11/24/2015 09:26 AM, Stuart Marks wrote: > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151123/ * It is mildly puzzling why the HashMap initial capacity is different from the number of elements you are about to push -- need to spell out that we are ad

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/24/2015 03:35 AM, John Rose wrote: > On Nov 23, 2015, at 1:42 PM, Aleksey Shipilev > mailto:aleksey.shipi...@oracle.com>> wrote: >> >> Okay, here it is (only tests changed): >> http://cr.openjdk.java.net/~shade/8136500/webrev.06/ >> <http://cr.open

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 08:58 PM, John Rose wrote: > On Nov 23, 2015, at 8:23 AM, Ivan Gerasimov > wrote: >> >> Though, it may be better to get yet another pair of eyes. >> >> One minor nit: In the tests, in the summary, it is written, "Test >> Integer.toString method*s*",

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 09:05 PM, Aleksey Shipilev wrote: > On 11/23/2015 08:58 PM, John Rose wrote: >> On Nov 23, 2015, at 8:23 AM, Ivan Gerasimov > <mailto:ivan.gerasi...@oracle.com>> wrote: >>> >>> Though, it may be better to get yet another pair of eyes. >

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 08:58 PM, John Rose wrote: > On Nov 23, 2015, at 8:23 AM, Ivan Gerasimov > wrote: >> >> Though, it may be better to get yet another pair of eyes. >> >> One minor nit: In the tests, in the summary, it is written, "Test >> Integer.toString method*s*",

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 04:34 PM, Ivan Gerasimov wrote: > With this fixed patch: > http://cr.openjdk.java.net/~igerasim/8136500/8136500-addition-1.patch > all tests from test/lang pass. > > Would you give it another chance? Okay, but this is better be the last non-cosmetic change to board this departing tr

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 12:36 PM, Ivan Gerasimov wrote: > A couple of concerns, though: > 1) > Wouldn't it be clearer to have "(byte)('0' + q);" instead of "(byte)(48 > + q); // 48 is ASCII '0'"? > I see that '0' constant is used in arithmetic in some other places. Yes, okay: http://cr.openjdk.java.net/~s

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/22/2015 01:55 AM, Ivan Gerasimov wrote: >>> Second, I think, the code of stringSize() might be better inlined, if it >>> was used only once. >> No-no! That's a helpful little fella. Not-yet-integrated Indify String >> Concat uses Integer/Long.stringSize. > > I didn't really propose to manual

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

Hi Ivan! Update: http://cr.openjdk.java.net/~shade/8136500/webrev.02/ Performance data updated (shaves off 0.5 ns at most): http://cr.openjdk.java.net/~shade/8136500/notes.txt On 11/21/2015 11:38 PM, Ivan Gerasimov wrote: > Just by a coincidence, I was experimenting with the same piece of code

RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

Hi, We have discovered this both in Compact Strings and Indy String Concat work, but it deserves to be treated separately. Integer/Long getChars code seems to be very old (Josh Bloch estimated circa 1994) and written under the assumption no compiler is here to help us. Fast-forward 20 years, and

Code (Pre-)Review for JEP 280: Indify String Concat

Hi, I would like to have a code pre-review for Indify String Concat changes. For the reference, the rationale, design constraints, etc. are outlined in the JEP itself: https://bugs.openjdk.java.net/browse/JDK-8085796 The experimental notes, including the bytecode shapes, benchmark data, and ben

Re: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character

On 11/18/2015 01:08 AM, Claes Redestad wrote: > On 2015-11-17 22:13, Remi Forax wrote: >> Hi Claes, >> I fail to see how this code will not throw a CCE at runtime >>if (con instanceof Integer || con instanceof Byte || con instanceof >> Short || con instanceof Character) { >> emitIconstIns

Re: RFR: jsr166 jdk9 integration wave 2

On 11/17/2015 02:04 AM, Martin Buchholz wrote: > On Mon, Nov 16, 2015 at 2:42 PM, Aleksey Shipilev > mailto:aleksey.shipi...@oracle.com>> wrote: > ForkJoinWorkerThread.newThread/: > * I think this one requires CCC, because it changes public API in > newThread.

Re: RFR: jsr166 jdk9 integration wave 2

Hi Martin, On 11/17/2015 12:39 AM, Martin Buchholz wrote: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ CancelledLockLoops/: OK CheckedMapBash/: OK CompletableFuture/: OK ConcurrentHashMap/: OK ReentrantReadWriteLock/: OK atomic/: OK! jtregTests/: Glanced over it,

Re: RFR: 8029574: TreeMap: optimization of method computeRedLevel()

Good, thanks! -Aleksey On 11/16/2015 11:16 PM, Martin Buchholz wrote: > I renamed sz to size and added > > + * > + * @param size the (non-negative) number of keys in the tree to be > built > > > On Mon, Nov 16, 2015 at 12:01 PM, Aleksey Shipilev > mailto:

Re: RFR: 8029574: TreeMap: optimization of method computeRedLevel()

On 11/16/2015 10:46 PM, Martin Buchholz wrote: > https://bugs.openjdk.java.net/browse/JDK-8029574 > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TreeMap-optimization/ +1, cute. Need to mention this only works for non-negative "sz"? It's hard to define what is the result for negative "sz",

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

On 11/09/2015 02:13 PM, Claes Redestad wrote: >> Can we avoid shared secrets by doing the following? >> >> @HotSpotIntrinsicCandidate >> public static Byte valueOf(byte b) { >> if (b == 0) return ZERO; >> final int offset = 128; >> return ByteCache.cache[(int)b + offset]; >> } > > I

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 11/09/2015 01:43 PM, Chris Hegarty wrote: > On 02/11/15 10:45, Aleksey Shipilev wrote: >> On 11/02/2015 02:56 AM, Chris Hegarty wrote: >>> In line with the intended location for other VM annotations, >>> see 8138732 [1], @sun.misc.Contended should be moved >>&g

Re: RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation

On 11/08/2015 03:30 PM, Claes Redestad wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8141677 > webrev: http://cr.openjdk.java.net/~redestad/8141677/webrev.01/ The approach looks sensible. The implementation deserves a comment why Objects.hash is not used, because it is tempting to fold th

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

On 11/08/2015 04:43 PM, Claes Redestad wrote: > Hi, > > indy eagerly creates and initializes all integral type caches > (Byte$ByteCache, Short$ShortCache) which has a small, measurable > impact to jake startup and footprint. Exposing ZERO constants from Byte, > Character, etc which are guaranteed

Re: RFR (S): 8141536, 8141539: Minor java.lang.invoke improvements

Both improvements look good. Thanks, -Aleksey On 11/05/2015 05:07 PM, Claes Redestad wrote: > looking for reviews for two trivial improvements to java.lang.invoke: > > 8141536: MethodType field offset calculation could be lazy > > Webrev: http://cr.openjdk.java.net/~redestad/8141536/webrev.01

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 11/02/2015 02:56 AM, Chris Hegarty wrote: > In line with the intended location for other VM annotations, > see 8138732 [1], @sun.misc.Contended should be moved > to the jdk.internal.vm.annotation package. > > http://cr.openjdk.java.net/~chegar/8140687/00/ Changes look good to me. But what's t

Re: CharSequence.subSequence optimizations

On 10/29/2015 01:36 PM, Pavel Rappo wrote: >> On 29 Oct 2015, at 00:48, Aleksey Shipilev >> wrote: >> Doesn't that break when CharSequence implementation is mutable? >> E.g. with StringBuilder, you cannot return "this" when "end == >> StringBu

Re: CharSequence.subSequence optimizations

On 10/29/2015 02:35 AM, Pavel Rappo wrote: > While working with an API that extensively uses java.lang.CharSequence, I've > noticed most JDK implementations of CharSequence do not optimize for corner > cases in CharSequence.subSequence(int start, int end). Namely, > > 1. start == end (an empty

Re: RFR 9 8140598 : Unused variable stream in freetypeScaler.c fails compilation

On 10/27/2015 05:48 PM, Roger Riggs wrote: > Please review a minor fix to remove an unused variable that can causes a > build warning/failure. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-unused-local-stream-8140598/ I think that one is already fixed: http://hg.openjdk.java.net/jdk9/

Re: RFR: 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory

On 10/27/2015 04:51 PM, Claes Redestad wrote: > > > On 2015-10-27 14:21, Aleksey Shipilev wrote: >> On 10/25/2015 04:27 AM, Claes Redestad wrote: >>> when deserializing objects with references to themselves, >>> ObjectInputStream pointlessly marks the object as

Re: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module

On 10/24/2015 11:54 PM, Claes Redestad wrote: > webrev: http://cr.openjdk.java.net/~redestad/8066644/webrev.02 > bug: https://bugs.openjdk.java.net/browse/JDK-8066644 Looks good. Is there really no way to use the new DateTime API, and ditch the multiplication by 1000L here? 116 return ldt.toEp

Re: RFR: 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory

On 10/25/2015 04:27 AM, Claes Redestad wrote: > when deserializing objects with references to themselves, > ObjectInputStream pointlessly marks the object as a dependency of > itself, which increases memory required to deserialize certain memory > graphs. > > bug: https://bugs.openjdk.java.net/bro

Re: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?

On 10/21/2015 06:53 PM, Andrew Haley wrote: > On 10/21/2015 04:44 PM, Aleksey Shipilev wrote: >> Of course, this does not tell another (scary) part of the story, what if >> the Reference itself is not discovered as strong ref by GC, e.g. when it >> isn't published

Re: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?

Hi, On 10/21/2015 03:34 PM, Peter Levart wrote: > Say it is being used like that: > > ReferenceQueue queue = ...; > > WeakReference wr = new WeakReference(new Object(), queue); > > Is it possible that the newly constructed Object is found > weakly-reachable before the 'queue' is assigned to the

Re: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException

On 10/12/2015 06:56 PM, Alan Bateman wrote: > On 12/10/2015 16:09, Vyom Tewari wrote: >> Bug:JDK-8068887 : java.lang.Throwable could use >> Collections.emptyList for suppressedException >> Webrev: http://cr.openjdk.java.net/~vtewari/8068887/webrev.00/webrev/ +1 > (Your patch makes me

Re: RFR [9] 8139307: Remove sun.misc.ConditionLock and Lock

On 10/09/2015 08:23 PM, Chris Hegarty wrote: > The functionality provided by these classes has long since been provided > by supported APIs in java.util.concurrent.locks. Nothing internal, or > external > ( to the best of my knowledge ), to the JDK is depending on these classes. > They should s

Re: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs)

On 10/08/2015 09:58 PM, Stuart Marks wrote: > On 10/7/15 12:59 PM, Sebastian Sickelmann wrote: >> http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/ >> >> jdk: >> The Boolean constructors are @Deprecated now so that we get >> compile-warnings for the uses. See also [0] and [1] >> >>

Re: Spin Loop Hint support: Draft JEP proposal

Hi Gil, Glad to see this being addressed! On 10/04/2015 07:22 PM, Gil Tene wrote: > We propose to add a method to the JDK which would be hint that a spin > loop is being performed. E.g. > jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve > to a Java SE API, e.g. java.util.Perf

Re: JEP 254: Compact Strings thoughts: character ranges outside ASCII + EASCII blocks

Hi Simon, On 09/25/2015 01:01 AM, Simon Spero wrote: > [Some of this is may simple or prohibitively tricksy depending on alignment > constraints (even though it's restricted to Prime Multilingual Plane :-) ] > > For some not un-realistic use cases, the most significant bytes for all the > charact

Re: Review: Indify String Concat JEP

Hi Alan, Thanks for taking a look! On 09/21/2015 02:24 PM, Alan Bateman wrote: > On 18/09/2015 16:17, Aleksey Shipilev wrote: >> Please review the submitted "Indify String Concat" JEP. It seems >> complete to me: with working implementation, testing, and general >

Review: Indify String Concat JEP

Hi, I recently sent the review request to compiler-dev@ [1], but got no response. Resending at corelibs-dev@ to gain more exposure. Please review the submitted "Indify String Concat" JEP. It seems complete to me: with working implementation, testing, and general understanding of an issue. Start h

Re: @Finalized

On 08/26/2015 06:07 PM, Doug Lea wrote: > On 08/26/2015 10:12 AM, Andrew Haley wrote: >> On 08/26/2015 03:01 PM, Doug Lea wrote: >>> This is an issue of large importance to a small audience, >>> and is at the moment an orphan. To work out, I think it >>> requires at least some involvement from comp

Re: Lower overhead String encoding/decoding

On 06/03/2015 07:34 PM, Xueming Shen wrote: > I'm still planning to be the sponsor for this RFE and get this one > into the jdk9. We are current working on JEP 254 [1][2][3]in which > the internal storage mechanism is changed from char[] to byte[]. If > this JEP get approved and is scheduled to ta

Re: JEP 254: Compact Strings

On 06/01/2015 03:54 PM, Vitaly Davidovich wrote: > While it's true that the denser format will require fewer cachelines, my > experience is that most strings are smaller than a single cacheline > worth of storage, maybe two lines in some cases; there's just a ton of > them in the heap. So the heap

Re: JEP 254: Compact Strings

On 05/18/2015 05:35 PM, Vitaly Davidovich wrote: > This part is a bit unclear for the proposed changes. While it's true that > single byte encoding will be denser than two byte, most string ops end up > walking the backing store linearly; prefetch (either implicit h/w or > software-assisted) could

Re: JEP 254: Compact Strings

(getting back to this) Hi Jeremy, On 05/16/2015 03:34 AM, Jeremy Manson wrote: > So, I'm pretty dubious, mostly because of the risks mentioned in the JEP. > If you need a flag-check and two code paths for every String method, that's > going to make the String class more slow and bloated, and make

Re: Why isn't Object.notify() a synchronized method?

On 05/28/2015 07:08 PM, Ulf Zibis wrote: > Hi all, > > in the Javadoc of notify(), notifyAll() and wait(...) I read, that this > methods should only be used with synchronisation on it's instance. > So I'm wondering, why they don't have the synchronized modifier out of > the box in Object class. W

Re: Naming of thread pools (Executors)

On 05/17/2015 10:55 AM, Peter Hansson wrote: > Hi, > > I would like create a patch for > https://bugs.openjdk.java.net/browse/JDK-8016248. > MOTIVATION: Today thread pools created by the Executors method are always > prefixed with "pool". The developer can work around this by providing his own

Re: RFR: 8061254: SPECjvm2008-XML performance regressions in 9-b33

On 13.05.2015 14:51, Claes Redestad wrote: > 9-b33 introduced a sustained regression in SPECjvm2008 > xml.transform on a number of our test setups. > > JDK-8058643 removed the check on value.length > 0, which > means repeated calls to "".hashCode() now do a store of the > calculated value (0) to t

Re: RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

On 05/07/2015 06:00 PM, Ulf Zibis wrote: > May be: > ..., then a new internal array becomes allocated and refilled with > greater capacity. > > ... to give a hint, that this action may be expensive. The Javadoc already says "If the current capacity is less than the argument, then a new internal a

Re: RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

oger > > > > On 5/5/2015 4:31 AM, Aleksey Shipilev wrote: >> Hi Roger, >> >> On 05/01/2015 08:19 PM, Roger Riggs wrote: >>> Is there any additional benefit by rounding up the next multiple of 4 >>> or 8. >>> That would avoid a few wasted by

Re: RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

Hi Roger, On 05/01/2015 08:19 PM, Roger Riggs wrote: > Is there any additional benefit by rounding up the next multiple of 4 or 8. > That would avoid a few wasted bytes at the end of the buffer modulo the > allocation size. It does not seem to help any further. Tried "plus32-round8", as in: htt

Re: RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

Thanks for review, Ulf! -Aleksey. On 05/01/2015 05:29 PM, Ulf Zibis wrote: > Hi Aleksey, > > I like this approach and to me the webrev looks good. > > -Ulf > > > Am 24.04.2015 um 20:05 schrieb Aleksey Shipilev: >> Hi, >> >> This seems to be a simple

Re: RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

On 05/01/2015 10:14 PM, Bernd Eckenfels wrote: > btw just a small - maybe unrelated - observation on stock Java8u40. When > benchmarking String.valueOf/Integer.toString/""+n with JMH I noticed > that the compiler aided concatenation is the fastest, String concat desugaring and optimizations is a

Re: RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

Anyone? -Aleksey On 04/24/2015 09:05 PM, Aleksey Shipilev wrote: > Hi, > > This seems to be a simple one-liner fix, but the background is more > complicated. See the bug: > https://bugs.openjdk.java.net/browse/JDK-8076759 > > The bottom line is that our current resi

RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

Hi, This seems to be a simple one-liner fix, but the background is more complicated. See the bug: https://bugs.openjdk.java.net/browse/JDK-8076759 The bottom line is that our current resizing policy in ASB is hostile for long appends. There is a heuristics that extends the capacity to match the

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

On 04/01/2015 11:56 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/hotspot/ > http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/jdk/ > https://bugs.openjdk.java.net/browse/JDK-8057967 Glad to see this finally addressed, thanks! I did not look through the

Re: String.contains(CharSequence) calls toString on argument

If CharSequence is mutable and thread-safe, I would expect toString() implementation to provide the atomic snapshot (e.g. do the synchronization). Therefore, I find Sherman's argument interesting. On the other hand, we don't seem to be having any details/requirements for contains(CharSequence) w.r

Re: String.contains(CharSequence) calls toString on argument

On 03/20/2015 03:28 PM, Aleksey Shipilev wrote: > I wonder if the change is "only" about specializing > indexOf(CharSequence) on the Java side to shortcut to indexOf(String) > and others, like String.contentEquals(CharSequence) already does. Ah, sorry for the confusion, co

Re: String.contains(CharSequence) calls toString on argument

ial cases of indexOf(CharSequence) into the intrinsic as well. I wonder if the change is "only" about specializing indexOf(CharSequence) on the Java side to shortcut to indexOf(String) and others, like String.contentEquals(CharSequence) already does. > According to Aleksey Shipilev ( >

Re: Why not "weakNanoTime" for jdk9?

Hi guys, On 03/06/2015 11:14 PM, Andrew Haley wrote: > On 03/06/2015 07:35 PM, Martin Buchholz wrote: >> We all know that nanoTime has problems. It would really help if you list what problems weakNanoTime is supposed to solve. > Many (most?) users of nanoTime, >> especially for benchmarking or

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

On 02/19/2015 05:51 PM, Aleksey Shipilev wrote: > Hi, > > Please review and sponsor this cleanup fix: > http://cr.openjdk.java.net/~shade/8073479/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8073479 > > Summary: use Objects.requireNonNull instead of object.ge

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

On 02/20/2015 03:48 PM, Peter Levart wrote: > Good to know that requireNonNull is mostly not an issue after all. Double-checking: you're OK to push the change, right? -Aleksey.

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

On 02/20/2015 05:51 PM, Vladimir Ivanov wrote: >> Vladimir, >> >> Can you take a look if java.lang.invoke.* changes look good for you? >>http://cr.openjdk.java.net/~shade/8073479/webrev.00/ > Looks good. Thank you for review! -Aleksey.

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

On 02/20/2015 04:15 PM, Vladimir Ivanov wrote: >> So we hope for Objects.requireNonNull to be inlined most of the times. >> It would be nice if @ForceInline annotation was accessible outside >> java.lang.invoke package, so methods like requireNonNull could benefit >> from it too. With modules, such

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

Hi Peter, Thanks for additional testing! On 02/20/2015 03:48 PM, Peter Levart wrote: > So we hope for Objects.requireNonNull to be inlined most of the times. Yes, I think so, otherwise it is a platform bug :) And, as I said in reply to Vitaly, the ultimate answer would be to intrinsify Objects.r

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

On 02/19/2015 09:36 PM, Vitaly Davidovich wrote: > The problem is microbenchmarking this may not tell the true story (like > all microbenchmarks). In this case the explicit test and branch is > probably perfectly predicted because there's not much code. In a bigger > application, where the histor

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

On 02/19/2015 06:17 PM, Peter Levart wrote: > On 02/19/2015 04:02 PM, Aleksey Shipilev wrote: >>> >Hi Aleksey, >>> > >>> >Is profile pollution problem already fixed? Can Objects.requireNonNull >>> >be used in performance critical code without f

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

Hi Daniel, On 02/19/2015 06:03 PM, Daniel Fuchs wrote: > +1 for the java.logging changes :-) Good, thank you! > I wonder whether there was a subtle reason for calling > .getClass() in java.lang.invoke? Maybe class initialization > or whatever? As far as I understand, if you are checking the arg

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

back on this and I think it was shown > that profile pollution does impact this. If the requireNonNull sees > nulls it won't use implicit null check. > > sent from my phone > > On Feb 19, 2015 10:03 AM, "Aleksey Shipilev" > mailto:aleksey.shipi...@oracle.com&g

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

Hi Peter, On 02/19/2015 05:59 PM, Peter Levart wrote: > On 02/19/2015 03:51 PM, Aleksey Shipilev wrote: >> Hi, >> >> Please review and sponsor this cleanup fix: >>http://cr.openjdk.java.net/~shade/8073479/webrev.00/ >>https://bugs.openjdk.java.net/brow

RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

Hi, Please review and sponsor this cleanup fix: http://cr.openjdk.java.net/~shade/8073479/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8073479 Summary: use Objects.requireNonNull instead of object.getClass to check for nullity. Testing: - jdk9-dev build on Linux x86_64/release - J

Re: Time to retire System.runFinalizersOnExit?

On 27.01.2015 07:37, Mandy Chung wrote: > System.runFinalizationOnExit has been deprecated since 1998 (JDK 1.2) > and this method is inherently unsafe. I am thinking to propose this method > in JDK 9 to throw UnsupportedOperationException. > > I believe it's rare for existing applications using >

Re: RFR(S): 8067471: Use private static final char[0] for empty Strings

On 21.12.2014 18:37, Lev Priima wrote: > Thanks for exhaustive research. Looks formal enough to claim that both > variants of change bring only perf advantages, but, as I understand, > which one is better is not so straightforward. Both are sound performance-wise, and you can see that they produce

Re: RFR(S): 8067471: Use private static final char[0] for empty Strings

On 12/19/2014 03:41 AM, Lev Priima wrote: > By naive glance, new constructor thrpt is bigger(jdk9/dev vs 9b42 > in attach) on: > @Benchmark > public String getNewString() { > return new String(); > } This is how you do it: http://cr.openjdk.java.net/~shade/8067471/ http://cr

Re: RFR(S): 8067471: Use private static final char[0] for empty Strings

On 17.12.2014 18:58, Claes Redestad wrote: > On 2014-12-17 11:22, Lev Priima wrote: >> Please review space optimization in no args String constructor. >> Originally, it was already rejected once by suggestion in >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html >> w/o for

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

On 12/01/2014 07:58 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057020 Looks okay, although the cache management logic gives me a headache after the vacation. I thought I spotted a few bugs, but those were only fa

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

Hi, On 12/02/2014 01:02 PM, Paul Sandoz wrote: > Please find below a patch to remove the networking code computing a > seed in ThreadLocal/SplittableRandom. Looks good. > We thought it a good idea at the time :-) but subsequently on certain > platforms this results in very high initalization cos

Re: JEP 198 JDK-8046390 involvement

Hi Hendrik, On 11/28/2014 03:40 PM, Hendrik Dev wrote: > Is it enough to read this mailing list or are other sources more > recommended and is http://hg.openjdk.java.net/jdk9/dev/jdk/ the > correct repo? I think yes, and yes. Joe Wang (JEP assignee) is on this list. -Aleksey.

Re: More memory-efficient internal representation for Strings: call for more data

Hi Douglas, On 12/03/2014 02:24 AM, Douglas Surber wrote: > String construction is a big performance issue for JDBC drivers. Most > queries return some number of Strings. The overwhelming majority of > those Strings will be short lived. The cost of constructing these > Strings from network bytes i

<    3   4   5   6   7   8   9   10   11   >