RFR: 8223056: Remove Type-Stable-Memory support for Parkers

[Coleen Phillimore]

On Fri, 15 Jan 2021 04:35:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As per the bug report, once we ensure the calls to unpark() are guaranteed to only occur on a live thread (protected by a ThreadsListHandle) Parkers (the synchronization object underlying java.util.concurrent.LockSupport) no longer need to use type-stable-memory (TSM).
> 
> As a Parker is inherently associated with a single JavaThread, the Parker is now embedded directly in JavaThread, avoiding the need to use new/delete.
> 
> The Parker and PlatformParker classes are now simplified from a memory management perspective. I also made them NONCOPYABLE for good measure. Possibly other constraints could be applied to them such as disallowing new/delete? (Though if we go that far maybe we need a new allocation base type?).
> 
> Testing: tiers 1-3 plus additional test builds
> 
> Thanks,
> David

Changes requested by coleenp (Reviewer).

src/hotspot/share/runtime/park.hpp line 58:

> 56: 
> 57:  public:
> 58:   Parker() : PlatformParker(), _counter(0) {

nit generally when empty } is on the same line as {.

src/hotspot/share/runtime/park.cpp line 112:

> 110: 
> 111: void ParkEvent::operator delete (void * a) {
> 112:   // ParkEvents are type-stable and immortal ...

Do ParkEvents still need to be type-stable and immortal as a future RFE?

src/hotspot/os/windows/os_windows.hpp line 205:

> 203:     CloseHandle(_ParkEvent);
> 204:   }
> 205: };

Should the implementation of the constructor and destructor be in the .cpp file so that thread.hpp doesn't need to include whatever windows os specific file needed to import CreateEvent and CloseHandle?

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

PR: https://git.openjdk.java.net/jdk/pull/2089