8198888: Reduce string allocation churn inInvokerBytecodeGenerator

[Bernd Eckenfels]

+        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)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

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

Hi,

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

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

Thanks!

/Claes