Re: 4.0.0 JNI/reflection invocation 2/4/8 times as slow as in 3.3.3

[Tom Tromey <tromey at redhat dot com>]

Jost> Imagine a program which allocates and immediately removes a key.  If you
Jost> let the hash() distribute the keys all over the table, your table gets
Jost> filled with tombstones.  And since a tombstone prevents a key to be
Jost> entered immediately, our hash table has degenerated into a linear list
Jost> which could have a length of up to 75% of it.  What would help is to
Jost> change the implementation to allow more than one key at a location, for
Jost> example by storing the additional keys in a separate list or by building
Jost> clusters.

That's interesting.  Could you write a patch that includes an
explanation of what is going on internally?  And ideally do some
profiling so we can see the result?

The bigger change here would be to avoid using IdentityHashMap as much
in JNI.  This could be done by arranging for the local reference table
to be scanned by the GC (this isn't completely trivial unfortunately).

Tom