RFR: 8061254: SPECjvm2008-XML performance regressions in 9-b33 (original) (raw)
Claes Redestad claes.redestad at oracle.com
Wed May 13 11:51:05 UTC 2015
- Previous message: [Annotation Processor] Accessing type annotations on VariableElement at compile time
- Next message: RFR: 8061254: SPECjvm2008-XML performance regressions in 9-b33
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Annotation Processor] Accessing type annotations on VariableElement at compile time
- Next message: RFR: 8061254: SPECjvm2008-XML performance regressions in 9-b33
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]