While reviewing the fix for JDK-4505697 an observation was made about the exceptions thrown from within "set_initialization_state_and_notify()" method not being reported by JVMTI.

David Holmes wrote:
===
set_initialization_state_and_notify is often called when an exception has already occurred during the class loading/initialization process. It is that original exception that we want to propagate but meanwhile we have to perform this action to update the state and wakeup any waiters. So we cache the original exception, clear it, do the state update and then clear any pending exception (I think the only exception possible here is OOME!), then rethrow the original. If this action did indeed throw OOME then we might not be able to wake up the waiter(s) and that might lead to a hang. While a debug VM could use TraceExceptions to (hopefully) spot the OOME, in a product VM it would be invisible, even if a JVMTI agent was tracking exceptions. So I think it should be visible to JVMTI
===