RFR: 8292077: G1 nmethod entry barriers don't keep oops alive

[Erik Österlund]

The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed.

There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load.
I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong.

-------------

Commit messages:
 - 8292077: G1 nmethod entry barriers don't keep oops alive

Changes: https://git.openjdk.org/jdk/pull/9817/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292077
  Stats: 22 lines in 1 file changed: 16 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9817.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9817/head:pull/9817

PR: https://git.openjdk.org/jdk/pull/9817