RFR: 8324514: ClassLoaderData::print_on should print address of class loader [v3]

[Coleen Phillimore]

On Tue, 23 Jan 2024 13:32:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This looks like a simple diagnostic regression from [JDK-8201556](https://bugs.openjdk.org/browse/JDK-8201556). Instead of printing the address of the `OopHandle` slot, we really want to print the address of the classloader that handle holds. That was not intentional, right, @coleenp?
>> 
>> I think we can `peek()` into handle, but the whole reason for [JDK-8201556](https://bugs.openjdk.org/browse/JDK-8201556) seems to avoid touching the classloader oops when unloading, and `peek()` would do a GC barrier on it. We could specialize for `!unloading` path, but I think we still want to see what is in the handle. So, this PR introduces the "peek_raw" version that would compile straight to plain access, after the null check.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   peek_raw

src/hotspot/share/classfile/classLoaderData.cpp line 1006:

> 1004:     out->print_cr("");
> 1005:   }
> 1006:   out->print_cr(" - class loader        " INTPTR_FORMAT, p2i(_class_loader.peek_raw()));

This peek_raw feels like a dangerous addition. Could be misused(?)  @kimbarrett has been looking at OopHandle, maybe he has an opinion.  I can't remember why/whether we can't do a peek on an unloaded class loader. Also @fisk is the definitive source of this info (plus you guys on Shenandoah too).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17534#discussion_r1463320805