RFR (S) 8134758: Final String field values should be trusted as stable

Tobias Hartmann tobias.hartmann at oracle.com
Tue Sep 1 06:52:27 UTC 2015


Hi Aleksey,

On 31.08.2015 22:36, Aleksey Shipilev wrote:
> Current JDK 9 code captures T_INT constants there, but we need T_BYTE as
> well. Compact Strings version has even more constant types handled, but
> not T_BYTE [1] (this should be the leftovers from CompressedStrings).
> Tried to hack T_BYTE there for Compact Strings, and the same performance
> effect was achieved.

Yes, Compact Strings handles T_OBJECT and T_BOOLEAN as well because they were needed for the old String.value which was Object and the "coder" field which was boolean. Actually, I was just working on cleaning up that code and making it aware of the new T_BYTE coder field (discussed it with Vladimir last week).

The T_INT is most likely also legacy code from when we still had the String.count field. I think you can remove it.

> I'll see how and where to fix this properly. Tentatively, I'd say all
> types should be handled in the mainline version, and Compact Strings
> should purge its own version, to avoid further omissions.

Not sure if that makes sense, since JDK9 has no T_BYTE field in String.

> 
> Thanks,
> -Aleksey
> 
> [1]
> http://hg.openjdk.java.net/jdk9/sandbox/hotspot/file/c3a11189c852/src/share/vm/opto/memnode.cpp#l1732
> 


More information about the hotspot-compiler-dev mailing list