// Exposed during graal testing

HotSpotSpeculationLog wraps access to the native speculation log. It contains internal data for the list of failed speculations in form of an array https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java#L164 that can be null.
This array is normally filled in HotSpotSpeculationLog#collectFailedSpeculations. Callers of the API - like graal can call this method to read native speculation log entries. However, the method HotSpotSpeculationLog#maySpeculate also calls collectFailedSpeculations. This creates an inconsistency race for JVMCI based compiles. If a compilation starts out and no speculations failed yet the failedSpeculations field is not set - then during the compile a speculation fails in another thread - and the next time somebody calls maySpeculate the failedSpeculations field is propagated. This can cause troubles if the users of the API, like Graal, expect the speculation log to not change during a single compile.

The fix is simple - not call collectFailedSpeculations in maySpeculate.