signatures and fingerprints and adapters (oh my!)

[John Rose]

I have done some proof of concept work consolidating the JVM’s signature scanning code.
It’s documented at https://bugs.openjdk.java.net/browse/JDK-8230199.

Lois and Claes have started looking at it (thank you!!) and if all goes well it will be worth
reviewing more widely, pretty soon.

As a spin-off of that, I noticed that it is profitable to front-load the computation of a 64-bit
signature “fingerprint” for each method.  This is currently the job of the Fingerprinter class,
which is designed as a lazily computed accelerator for specific signature-processing
tasks.  But since the class file parser needs to make *at least one* pass over every
signature, it’s reasonable to extend one of those passes to compute the 64-bit fingerprint.
(This removes some fiddly details with volatile and CAS that were a cost of lazy evaluation.)

What are the passes that the class file parser makes over signatures?

- syntax verification (not in java.base unless -Xverify:all)
- result type extraction (always!)
- argument word counting (always!)

The current code has a hack which merge syntax verification (if requested) with argument
word counting, but makes a separate pass for result type extraction.  Later on a fingerprint
may be lazily computed (from cold data, at that point).  The POC for JDK-8230199
consolidates these computations into a single pass, including fingerprint extraction.
The consolidated loop appears to offer a tiny speedup (~1ms on startup), and it’s also
more maintainable.  In my opinion.

So, now that fingerprints are eager rather than lazy, I started looking around for other
fingerprint-like structures, and (lo and behold) found class AdapterFingerPrint, which is
*also* eagerly computed at load time (when a method’s adapters are eagerly linked).
There’s a performance, footprint, and simplicity gain here, if we can merge the two things
together.

If I have time I may look further into this, but perhaps someone else is interested?
I filed a tracking bug https://bugs.openjdk.java.net/browse/JDK-8231285.

I took on the signature code because it seems to add friction to the changes Valhalla
needs to make to descriptor syntax.  Although I’m kind of itching to tackle the fingerprint
code also, that realistically could stay the way it is for the next 20 years without severe
damage.  But maybe there’s a performance or footprint motivation for tackling it.  So it
may in fact by a Claes-shaped bug.  :-)

— John