RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]

[Thomas Stuefe]

On Tue, 7 Feb 2023 15:40:34 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to JDK
>   
>   Signed-off-by: Justin King <jcking at google.com>

I read through your explanation, and through the [design docs](https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizerDesignDocument), but my question remains unanswered. See below.

> > Metaspace objects hold pointers to malloced memory. Metaspace Objects can leak, that's accepted. So these pointers would leak too. Would that not give us tons of false positives?
> 
> No. LSan only cares that it can find pointers to malloc'ed memory, not that it can find pointers to Metaspace objects. The Metaspace is registered as a root region. It does however take into account ASan poisoning, which we added earlier to Metaspace. LSan will not scan poisoned memory regions that are part of root regions. We only poison in Metaspace when deallocation occurs and unpoison when allocation occurs.

But they are not poisened.

Upon JVM end, the heap still exists, holding class loaders, which hold references to CLDs. Those hold metaspace arenas (living in Metaspace), which hold Metaspace chunks, which are registered LSAN root areas, which hold C-allocated sub structures. These chunks are not poisened since they have never been returned to the chunk pool. They are still alive.

To put it in other words: even I as a human cannot determine that this is not a C-heap leak. Technically, it is. But it is accepted since we accept these things leaking. Since we don't support unloading and re-loading the JVM, we accept that to have a faster shutdown.

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

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