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
