On Wed, 1 Feb 2023 15:26:27 GMT, Justin King <jck...@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 rely on testing compressed oops or compressed class >> pointers. 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:** >> - `UseCompressedOops` and `UseCompressedClassPointers` are forced to false >> when LSan is enabled. This is necessary to ensure all pointers to memory >> which could possible container pointers to malloc memory are property >> aligned, which is an LSan requirement. >> - By default ASan enables LSan, however we explicitly disable it unless >> `--enable-lsan` is given. This is due to the other caveats. 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. >> - There are a series of tests that are upset due to the above flags being >> forced false, as they rely on the arguments being supported. In the future >> ideally these tests would be skipped nicely when LSan is enabled. > > Justin King has updated the pull request incrementally with one additional > commit since the last revision: > > Support CDS > > Signed-off-by: Justin King <jck...@google.com> I think this is very useful, but the reliance on -UseCompressedOops and -UseCompressedClassPointers is unfortunate. Especially the latter. With Project Liliput, we plan to eliminate uncompressed class pointers altogether (there is really no good reason to not have them even in today's JVM unless you plan to load more than ~4million classes). ------------- PR: https://git.openjdk.org/jdk/pull/12229
