RFR: 8298601: Refactor archiving of java.lang.Module objects
Ioi Lam
iklam at openjdk.org
Tue Dec 20 17:04:50 UTC 2022
On Tue, 20 Dec 2022 13:48:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> This RFE is a prerequisite for [JDK-8296344: Remove dependency on G1 for writing the CDS archive heap](https://bugs.openjdk.org/browse/JDK-8296344).
>>
>> The main change of this RFE is in `HeapShared::archive_reachable_objects_from()`. We avoid the use of "archived objects" in the interface between CDS and the module system, and use integer "root indices" instead. (See note [1] in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600).)
>>
>> Also, for better encapsulation, the module-specific code has been moved from `HeapShared::check_module_oop()` to the three new functions in modules.cpp.
>>
>> ----
>>
>> Besides the refactoring, this RFE also tightens up the code that deals with `java.lang.Module` oops and the corresponding C++ `ModuleEntry` objects.
>>
>> As this is admittedly an obscured area of the CDS archive heap, I've added the following:
>>
>> - Assertions to make sure that when an oop is archived, the corresponding C++ object is also archived, and vice-versa.
>> - More comments
>
> src/hotspot/share/classfile/moduleEntry.cpp line 552:
>
>> 550: if (log_is_enabled(Info, cds, module)) {
>> 551: ResourceMark rm;
>> 552: log_info(cds, module)("Restored archived %s", debug_info());
>
> I don't know if stringStream needs a resource mark so if it doesn't, you can just have one log line for these.
I used `StringStream::as_string(bool c_heap = false)` to return from `debug_info()`, so the result is resource allocated.
Anyway, I can see that this style may be confusing. I'll rewrite it to follow the `print_on(st)` style that's more common where the semantics are well understood. This will make the logging a little more tedious but I think it's OK.
-------------
PR: https://git.openjdk.org/jdk/pull/11715
More information about the hotspot-runtime-dev
mailing list