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