JDK-8269423: ZGC: Support pinned Object and remove/simplify GCLocker usage in ZGC

[Hamlin-Li]

This PR is not an real intention to push current implementation, and current implementation does not support ZVerifyViews (which was pointed out by Per at #4638 (comment)).

Let's see if this solution is feasible and how to support ZVerifyViews efficiently.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8269423: ZGC: Support pinned Object and remove/simplify GCLocker usage in ZGC

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4650/head:pull/4650
$ git checkout pull/4650

Update a local copy of the PR:
$ git checkout pull/4650
$ git pull https://git.openjdk.java.net/jdk pull/4650/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4650

View PR using the GUI difftool:
$ git pr show -t 4650

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4650.diff

[bridgekeeper]

👋 Welcome back mli! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@Hamlin-Li The following label will be automatically applied to this pull request:

• hotspot-gc

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (a1dfc9f0)

[pliden]

I suggest we close this PR for now and revisit this once we have the generational work in place, since that might open up some doors for this.

One thing to also keep in mind is that ZGC is less affected by the GC locker than an STW collector is, since all the GC locker does is potentially delaying the start of the marking and relocation phases. In a STW collector context it typically also blocks allocations from happening, which isn't the case in ZGC. So, I am a bit curious if you have actually seen GC locker related problems with ZGC?

Finally, just a quick comment on the code. I see you moved the installation of the relocation set and the setup of forwarding tables into ZHeap::relocate_start(). This means this will now be executed in a STW pause, which is not an option as those operations can be quite expensive and are not O(1).

[Hamlin-Li]

I see your points, thanks for the deailed comments!
I'm OK to close the PR for now, and will come back then to investigate the issue to see if there will be better solution.
For your question, I don't see such problem in production, but seems it could be a potential issue for some use cases.