VtableStubs::stub_containing() loops over the hash table buckets to see if the given address is a i/vtable stub.

For every bucket, it loads the head and the next pointers with unordered loads; the store to the head pointer in enter() is also unordered wrt to the next pointer and that load, so stub_containing() could read garbage for the next field and return a wrong result.

Found by code inspection for JDK-8317527.

It's very unlikely to do so (and there may be some proof like "between the store and the load there almost likely is some intervening synchronization"), and probably never happened so far.

The simplest thing is to make this ordering explicit (and remove the

  // Note: No locking needed since any change to the data structure
  // happens with an atomic store into it (we don't care about
  // consistency with the _number_of_vtable_stubs counter).

comment which is wrong about the "no synchronization" needed.)