Review request for JDK-8011095 PropertyHashMap.rehash() does not grow enough

Jim Laskey (Oracle) james.laskey at oracle.com
Mon Apr 1 04:35:29 PDT 2013


The "set" callsite for "this.foo = ..."  has a predefined map as an constant argument to the setSpill/setSpillWithGrow/setSpillWithNew call.  So every object that goes thru that path gets the same map.  Even with conditional paths, a polymorphic callsite will produce maps shared by similar objects.  What we end up with is a similar effect to histories embedded in the code.

-- Jim


On 2013-04-01, at 2:11 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> hmm.. For constructors, we start with an empty map and keep growing it with every "this.foo" assignment, right? If no history, how constructors generated objects will share maps? Or am I missing something?
> 
> -Sundar
> 
> On Sunday 31 March 2013 04:46 PM, Jim Laskey (Oracle) wrote:
>> I well tested.  Beginning to believe that history in general may not be worth it, since it does take up considerable space and is somewhat compensated by predefined maps at set call sites.
>> 
>> 
>> On 2013-03-31, at 5:08 AM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
>> 
>>> What Hannes said. Also looks good. Pls do some performance verification.
>>> /M
>>> 
>>> On Mar 30, 2013, at 4:40 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>>> 
>>>> Looks good to me. The one thing I'm not sure about is the implications of not caching history for empty properties. On the one hand it seems plausible to avoid creating a huge property map tree where nothing is ever garbage collected, but on the hand everything starting at the empty properties map will not use history while still recording it, which is a wasted effort.
>>>> 
>>>> I think we should do some testing with octane to see what operations actually use history or not with this scheme.
>>>> 
>>>> Hannes
>>>> 
>>>> 
>>>> Am 2013-03-30 14:53, schrieb Jim Laskey (Oracle):
>>>>> Please review http://cr.openjdk.java.net/~jlaskey/8011095/webrev.00/
>>>>> 
> 



More information about the nashorn-dev mailing list