RFR: 8323950: Null CLD while loading shared lambda proxy class with javaagent active
Calvin Cheung
ccheung at openjdk.org
Tue Jan 30 18:47:00 UTC 2024
On Sat, 27 Jan 2024 00:25:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:
> A simple fix for an assert failure when an archived interface of an archived lambda proxy class is being transformed using
> a java agent during runtime. Please refer to the bug report for details.
>
> Testing: passed tiers 1 - 4 (including the new test).
Thanks for taking a look.
> These nulled out CLD fields in class loaders are troubling to me. The GCs are not built to cope with them. The code for marking through the heap assumes that surely a ClassLoader has a corresponding CLD, and crashes if it does not.
>
> While we can try to chase after every closure where this is a problem and add a null check, I have to wonder if it is the right solution.
>
The CLD for a shared class is usually setup during `SystemDictionary::load_shared_class`. In this case, since a super type of a shared class is being transformed during runtime, the `SystemDictionary::load_shared_class` returns null early due to the fail check in `check_shared_class_super_types`. So I think the fix is okay for now; it is just a small adjustment to the original fix for JDK-8296433.
> I wonder, if the CLD could be archived as well, or something like that.
>
We can file an RFE later if it deems beneficial to do so.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17602#issuecomment-1917674682
More information about the hotspot-runtime-dev
mailing list