RFR: JDK-8327971: Multiple ASAN errors reported for metaspace [v3]

[Guoxiong Li]

On Wed, 13 Mar 2024 08:13:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> When adding ASAN support for metaspace, we decided to track poisoning not at the OS border (map) but at the border between metaspace and outer JVM code (or, more precisely, at the border of ChunkManager chunk allocation/deallocation).
>> 
>> Chunks handed out by the chunk manager are unpoisoned, poisoned when handed back.
>> 
>> This causes some problems, since within metaspace we access memory that is committed but not yet handed to the user. So from the ASANs view, that memory is poisoned; from the view of the metaspace allocator, these accesses are perfectly valid.
>> 
>> Basic problem here is ASAN does not distinguish between illegal access from JVM caller code and legal access from within metaspace. 
>> 
>> The fixes required are minor. Without them even the ASAN build will fail. The ASAN errors are mostly caused by sections that are guarded with `MetaspaceTestInterval`.
>> 
>> With the patch, ASAN build succeeds, and we survive metaspace gtests with `MetaspaceTestInterval` cranked up to the highest level.
>
> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove stray newline
>  - fixes

src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 438:

> 436:   // Down here, from ASAN's view, this memory may be poisoned, since we only unpoison
> 437:   // way up at the ChunkManager level.
> 438: #if !INCLUDE_ASAN

> But from the newest code, which uses only INCLUDE_ASAN instead of ASAN_ONLY and NOT_ASAN, I think you can use the exiting ADDRESS_SANITIZER instead of adding INCLUDE_ASAN

For example, you can use `#ifdef ADDRESS_SANITIZER` directly here and don't need a new macro `INCLUDE_ASAN`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18230#discussion_r1522818537