RFR: JDK-8293346: Add NoThreadCurrentMark to simulate non-attached threads

David Holmes dholmes at openjdk.org
Wed Sep 21 06:50:39 UTC 2022


On Tue, 6 Sep 2022 06:37:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> When working on [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344), I needed a way to verify that I had removed all offending usages of ResourceArea memory inside an extend.
> 
> For that, a NoThreadCurrentMark was useful. It temporarily sets the current Thread* to NULL for the extend. Any use of Thread::current below that mark will now crash or assert.
> 
> This can be used for two things:
> - guard code that is supposed to be safe for non-attached threads (os::malloc, stack printing, UL etc) against accidental usage of Thread::current() (e.g. resource area allocation)
> - in gtests, simulate a non-attached thread to cover code that behaves differently with Thread::current()==NULL.
> 
> This patch:
> 
> - Introduces the debug-only `NoThreadCurrentMark`
> - Adds a gtest for it
> - Adds it to guard dwarf-parsing-based stack printing, which had not been safe due to use of ResourceArea, fixed with  [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344)
> - Adds it to `os::malloc()`, `os::realloc()` and `os::free()`, since those can certainly be called without a current thread.
> - Replaces the test-local mark in the SafeFetch gtests that did a similar thing
> - I may add and fix up other users later
> 
> I also had to change Library-based TLS initialization such that it runs at C++ dynamic initialization time. That is because the `NoThreadCurrentMark` needs to set both Library-based TLS and C++ TLS slots, and having library-based TLS not available before VM initialization made the code too complex. This also means we can remove the explicit TLS initialization from create_vm.
> 
> Finally, while I was here, I also fixed the error printing in library based TLS (since the pthread_key_xxx functions don't modify errno).

A counter rather than a bit allows nesting easily enough. As this is just a debugging/testing aid it really shouldn't disrupt product code IMO. Thanks.

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

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


More information about the hotspot-dev mailing list