On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter <[email protected]> wrote:
> This fixes a race condition in the CompressionBackend class of the heap dump > code. > > The race happens when the thread iterating the heap wants to write the data > it has collected. If the compression backend has worker threads, the buffer > to write would just be added to a queue and the worker threads would then > compress (if needed) and write the buffer. But if no worker threads are > present, the thread doing the iteration must do this itself. > > The iterating thread checks the _nr_of_threads member under lock protection > and if it is 0, it assume it would have to do the work itself. It then > releases the lock and enters the loop of the worker threads for one round. > But after the lock has been released, a worker thread could be registered and > handle the buffer itself. Then the iterating thread would wait until another > buffer is available, which will never happen. > > The fix is to take the buffer to write out of the queue in the iterating > thread under lock protection and the do the unlocking. Dear Ralf(@schmelter-sap), I am not a reviewer, just want to state that this change looks good to me and also helpful. I have encountered an issue that happened 2 times among 100 times try when testing #2261. And after applied this change, it works normally for another 100 times test. Just FYI. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3628
