Compact header and computed hashCode

[Kennke, Roman]

Hi Remi,

> i was taking a look to the code submitted by Roman to avoid allocating hashCode if not necessary, pretending i'm able to read VM code, when an idea pop up.
> 
> I wonder if for small objects (64bits or less) containing only primitives, it's not better to not reserve a space for the hashcode at all and recompute it using the value of the fields ?

I guess we could. It would not be strictly an ‘identity’ hash-code, right - but still valid with respect to the contract hash(x) != hash(y) => x != y. I am not sure how useful that would be. The case where we need to allocate extra space is not so very frequent, and stuff like j.l.Integer or j.l.Long already override their hashCode() method, so would in most cases not be affected by this.

The other problem is that we have an intrinsic in C2 that handles the hash-code 	(see the changes in libraryCall.cpp). This code would also have to deal with that special case, and I am not sure if adding another branch there might not make all other (more common) cases slower.

I need to think this through…

Thanks,
Roman




Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597