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

[Aleksey Shipilev]

On 13.05.2015 14:51, Claes Redestad wrote:
> 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]

More details: it seems like xml.transform ends up using JDK APIs
(com.sun.org.apache.xml.internal.dtm.ref.ExpandedNameTable.getExpandedTypeID)
that "compute" the hashcode for "null" argument by calling
"".hashCode(), which is silly in itself.

Anyhow, dropping value.length > 0 check was my bad, and it is a yet
another manifestation of the empirical law in performance engineering:
 https://twitter.com/shipilev/status/539119320081907713

> 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/

Good.

Thanks,
-Aleksey