On Apr 1 2013, at 22:24 , Martin Buchholz wrote: (Other changes accepted as suggested)
> If we are willing to make small incompatible changes, how about when > serializing, storing capacity as the size, so that reconstituted ArrayLists > are pre-trimmed to size? Yes, I found it strange that clone() returns a trimmed copy and serialization preserved capacity. Recording size as capacity would be a difference but not an incompatibility (objects serialized by both old and new implementations could be deserialized correctly by old and new). > --- > > I still believe that with the help of the gc team, one can cook up a > trim-to-size when gc-ing fix, but that's going to be very hard to implement. I'm saving my VM RFEs for split arrays, huge arrays, sparse arrays and array pinning. :-) Mike > > --- > > > > > On Mon, Apr 1, 2013 at 7:00 PM, Mike Duigou <mike.dui...@oracle.com> wrote: > Hello all; > > I have posted an updated version of the empty ArrayList and HashMap patch. > > http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ > > This revised implementation introduces *no new fields* to either class. For > ArrayList the lazy allocation of the backing array occurs only if the list is > created at default size. According to our performance analysis team, > approximately 85% of ArrayList instances are created at default size so this > optimization will be valid for an overwhelming majority of cases. > > For HashMap, creative use is made of the threshold field to track the > requested initial size until the bucket array is needed. On the read side the > empty map case is tested with isEmpty(). On the write size a comparison of > (table == EMPTY_TABLE) is used to detect the need to inflate the bucket > array. In readObject there's a little more work to try to choose an efficient > initial capacity. > > Mike > > On Mar 26 2013, at 17:25 , Mike Duigou wrote: > > > Hello all; > > > > This is a review for optimization work that came out of internal analysis > > of Oracle's Java applications. It's based upon analysis that shows that in > > large applications as much as 10% of maps and lists are initialized but > > never receive any entries. A smaller number spend a large proportion of > > their lifetime empty. We've found similar results across other workloads as > > well. This patch is not a substitute for pre-sizing your collections and > > maps--doing so will *always* have better results. > > > > This patch extends HashMap and ArrayList to provide special handling for > > newly created instances that avoids creating the backing array until > > needed. There is a very small additional cost for detecting when to inflate > > the map or list that is measurable in interpreted tests but disappears in > > JITed code. > > > > http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ > > > > We expect that should this code prove successful in Java 8 it will be > > backported to Java 7 updates. > > > > The unit test may appear to be somewhat unrelated. It was created after > > resolving a bug in an early version of this patch to detect the issue > > encountered (LinkedHashMap.init() was not being called in readObject() when > > the map was empty). > > > > Mike > >
