RFR: JDK-8298908: Instrument Metaspace for ASan [v2]

[Justin King]

On Tue, 10 Jan 2023 17:05:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I don't believe so, at least not based on current options. Other projects use similar tricks, like ABSL_DCHECK from Abseil which short circuits expressions when in non-debug builds causing the code to be unreachable and stripped. If it does, we can always just remove the if statement part and have it evaluate anyway. Most compilers should realize that the statements are unused and should be pruned.
>
> The macros `ASAN_POISON_MEMORY_REGION` and `ASAN_UNPOISON_MEMORY_REGION` are already defined in [sanitizer/asan_interface.h](https://opensource.apple.com/source/clang/clang-700.1.81/src/projects/compiler-rt/include/sanitizer/asan_interface.h.auto.html), but we redefine them here. 
> 
> Since ASan is going to be an obscured feature for many HotSpot developers, I don't think we should make it more obscured.
> 
> I think it's better to declare our own macros that call into the existing macros. Maybe something like 
> `_ASAN_POISON_MEMORY_REGION`. The comments should be improved to say why we do this (to prevent people that don't use ASan from breaking ASan).

I changed it to just use the macros directly when they are available instead of redefining it. When ASan is not present, both macros are equivalent to that provided by the header when ASan is not available. So it is not obscured.

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

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