RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

[Vladimir Ivanov]

Peter, Michael,

Very good work! I really like how CMH-based BMH & SpeciesData caches 
shape out in your proposal.

>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.04/

Small cleanup suggestion:
+        static boolean speciesDataCachePopulated() {
+            Class<BoundMethodHandle> rootCls = BoundMethodHandle.class;
              try {
                  for (Class<?> c : rootCls.getDeclaredClasses()) {
                      if (rootCls.isAssignableFrom(c)) {
                          final Class<? extends BoundMethodHandle> cbmh 
= c.asSubclass(BoundMethodHandle.class);

Maybe get rid of multiple BMH mentions here and just use Class<?> and 
rootCls?

> I think this is better then trying to disguise NoClassDefFoundError into
> a VirtualMachineError just in order to "fool" the test(s). This is how
> VM operates and in general, Error(s) thrown by VM should be propagated
> up to the top and reported as-is.
We already discussed that aspect. It's not only to fool the tests, but 
also to provide more meaningful error reporting. I don't think that 
NoClassDefFoundError is satisfactory. Remember, we started our 
investigations with a similar type of errors.

There are different ways to address the problem, but the most sensible 
IMO is:
   (1) split class initialization and Species instantiation;

   (2) on consecutive attempts after a failed one: either (a) repeat 
SpeciesData instantiation; or (b) cache first exception and return it.

I'd try to instantiate corresponding Species right away and act 
accordingly. CLASS_CACHE.computeIfAbsent() in getConcreteBMHClass 
guarantees unique call per key, so no need to piggyback on class 
initialization anymore. CLASS_CACHE (or CACHE entries?) can be used to 
store initialization state.

What do you think?

Best regards,
Vladimir Ivanov