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