RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

[Schmelter, Ralf]

Hi David,

thanks for the feedback. I fear you are right, the current code is not safe.

During much of the development I actually used a global lock. But then I thought it would look strange, that more than one CompressionBackend would use the same. But apart from aesthetics, this would pose no actual problem I can think of.

And I could move the code in ~ CompressionBackend to a deactivate() method, which would be called at the end of the VM operation. This way the mutex would only used during the actual VM operation, so there should be no problem even in theory.

So the easiest way to fix this would be to use a global lock instead, again. What do you think?

Best regards,
Ralf

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: Montag, 10. Februar 2020 23:20
To: Schmelter, Ralf <ralf.schmelter at sap.com>; Yasumasa Suenaga <suenaga at oss.nttdata.com>; OpenJDK Serviceability <serviceability-dev at openjdk.java.net>
Cc: yasuenag at gmail.com
Subject: Re: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

Hi Ralf,

One part of this caught my eye and now I look at the webrev I have some 
concerns. Introducing new threads to the VM is not something that should 
be done lightly and it has to be done very carefully - I need to look 
closer at this aspect. Further when using Mutexes/Monitors in such code 
you have to be extremely careful about how (or even if) those 
Mutex/Monitor get deleted. The code you have at present is not safe 
because you cannot know when other threads have completely exited the 
Monitor/Mutex code. The last thread to terminate will signal the 
destructing thread (blocked in wait) then release the monitor, allowing 
the destructing thread to acquire the monitor and then delete the _lock. 
But at the point at which the monitor becomes free and the destructor 
thread is unparked, the terminating thread may be context switched out 
and remain inside the Monitor code. The destructor thread then deletes 
the monitor and frees it. When the terminating thread resumes, if it 
touches any memory associated with the Monitor it could SEGV.

To safely delete a Monitor/Mutex you have to know for certain that all 
threads using it have completely ceased to use it. You cannot use that 
Monitor/Mutex as the means for determining that. It is a non-trivial 
problem to solve.

Cheers,
David
-----