8198888: Reduce string allocation churn inInvokerBytecodeGenerator

Bernd Eckenfels ecki at zusammenkunft.net
Thu Mar 1 18:39:22 UTC 2018

+        if (nameMap == null) {
+            nameMap = new HashMap<>(2);

What is the typical size the map ends up with? If it stays this small linearly searching an Array (or „last value“) may be faster.

If the map typically grows more than a few entries having some more initial buckets will decrease collissions and avoid resizes. Especially considering the fact that HashMap is a rather fat object, it does not hurt to start with a bigger initial table. Does the lazy initialisation actually help anything?

Single entry alternative
Object lastClass; String lastName;

If (lastClass == c)
  return lastName;
lastClass = c;
lastName = c.getName().replace(‘.‘, ‘/‘);
return lastName;

(or make it a x Slot Version…):
Object tab_obj = new tab_obj[8];
String tab_val = new String[8];

for(int i=0; i < tab_obj.length; i++)
  If (tab_obj[i] == c);
    return tab_val[i];
i = (i+1 % tab_obj.length);
tab_obj[i] = c;
return (tab_val[i] = c.getName().replace());

(not sure about the concurrent semantics and having this static may actually help)


Von: Claes Redestad
Gesendet: Donnerstag, 1. März 2018 16:15
An: core-libs-dev
Betreff: RFR: 8198888: Reduce string allocation churn inInvokerBytecodeGenerator


two trivial optimizations that get rid of a few percent on ISC startup 

Webrev: http://cr.openjdk.java.net/~redestad/8198888/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8198888



More information about the core-libs-dev mailing list