The jtreg test runtime/MemberName/ResolvedMethodTableHash.java
takes about half a CPU hour (on a macbook pro M1, fastdebug).

This is excessive for a jtreg test.

The test code has this comment:

// This should not take too long, unless Method hash
// function takes only the name and the signature as an input.

It looks like it has found the flaw it is looking for, or else
it is written wrong. Either way, something has to change.

It also appears that the test has no way to detect failure.
It just takes too long if the VM has a bug.
This is a problem as well.

I suggest putting in an assert in the relevant C++ or Java code
for the hashtable, that looks for ridiculous bucket lengths.

Such an assert is a reasonable idea for all of our tables.
The probability of a very long bucket is vanishingly small,
if the hashing method is even halfway decent, and
there is no intentional attempt to create collisions.

The assert should be suppressed by a diagnostic switch,
for any of our tests that intentionally create long buckets.

In fact, with a diagnostic switch, the assert might be
upgraded to a guarantee (off by default in product)
to help diagnose performance anomalies in the field.
The cost of the check would be an extra counter in
the bucket search loop of the hash code. If the
count goes above some set limit, the VM emits
a diagnostic of some sort.