RFR: 8061254: SPECjvm2008-XML performance regressions in 9-b33

[Sergey Bylokhov]

Just curious, what is the difference between this fix and an old version 
of the code:
http://cr.openjdk.java.net/~shade/8058643/webrev.01/src/java.base/share/classes/java/lang/String.java.sdiff.html

I meant:
"if (h == 0 && value.length > 0) {}"
vs
"if (h != 0) {hash = h;}"

On 13.05.15 14:51, Claes Redestad wrote:
> Hi,
>
> 9-b33 introduced a sustained regression in SPECjvm2008
> xml.transform on a number of our test setups.
>
> JDK-8058643 removed the check on value.length > 0, which
> means repeated calls to "".hashCode() now do a store of the
> calculated value (0) to the hash field. This has potential to
> cause excessive cache coherence traffic in xml.transform[1]
>
> Extracting the code that showed up in profiles to a micro[2] and
> running this in multiple threads is up to 100x slower in 9-b33 on
> a dual-socket machine.
>
> Adding back the check that value.length > 0 before entering the
> calculation loop recuperates the loss in both micro and
> xml.transform, but we're seeing as good or better number by
> simply guarding the store:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8061254/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8061254 (confidential
> due to links to internal systems, sorry!)
>
> This additionally avoids the field store (and potential for pointless
> cache traffic) also on non-empty strings whose hash value happen
> to equals 0.
>
> Thanks!
>
> /Claes
>
> [1] See 
> com.sun.org.apache.xml.internal.dtm.ref.ExpandedNameTable#getExpandedTypeID.
> [2] http://cr.openjdk.java.net/~redestad/8061254/expandedtypeid-micro.zip


-- 
Best regards, Sergey.