Serialisers.findWriters primitive wrapper lookup performance

[franz1981]

Describe the bug

#37646 da11e0f has by accident made quarkus to search for the writers in the hot path, making evident a possible performance improvement

Probably this is not supposed to be an hot path, but in case it will, it "could" be addressed at

quarkus/independent-projects/resteasy-reactive/server/runtime/src/main/java/org/jboss/resteasy/reactive/server/core/ServerSerialisers.java

Line 90 in 3c1d1a0

primitivesToWrappers.put(boolean.class, Boolean.class);

where's

quarkus/independent-projects/resteasy-reactive/common/runtime/src/main/java/org/jboss/resteasy/reactive/common/core/Serialisers.java

Line 50 in 3c1d1a0

if (primitivesToWrappers.containsKey(klass))

could be replaced by some different mechanism eg a chain of equality check guarded by Class::isPrimitive, which is an intrinsic.

[geoand]

Would simply doing:

if (klass.isPrimitive() && primitivesToWrappers.containsKey(klass)) 

be any better? I assume it would

[geoand]

I am also wondering if findResourceWriters can be improved while maintaining the semantics...

[franz1981]

There are few factors in place here:

• Class's identity hashcode first time is generated with https://github.com/openjdk/jdk/blob/486594d4273e9d5a8db43de861e3ca3ce823f0da/src/hotspot/share/runtime/synchronizer.cpp#L891 (see https://shipilev.net/jvm/anatomy-quarks/26-identity-hash-code/)
• but will be cached later on in the class's word (https://shipilev.net/jvm/anatomy-quarks/26-identity-hash-code/#_hashcode_storage)
• and 'Object''s equality which is used by Class::equals is just a reference equality

In short, in theory there are no reasons why it should be that slower, but still:

• it requires accessing the `HashMap''s different references which hold the keys to find it
• it requires pointer chasing the value's in the entry to be returned back

If the map is small enough, the map version should suffer from less branch-mispredictions (than the other version using the chain of if), but probably, in this case, due to the many indirections, is still slower.
The other pain point is that HashMap can can be reused in many occassions in the JIT code and if for "any" reasons (eg the stack depth is unlucky!) it couldn't be inlined, than it should relies on the type profile informations of the not inlined version of the same class, used elsewhere, with different key/value types, causing megamorphism or other performance quirk, on Object::hashCode or Object::equals.
In this case the safer choice, given that the cascade of if is not that long, the performance behaviour of the new version is just easier to predict and very expected, with none of the previous downsides.

[geoand]

Thanks for the analysis!