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
