RFR: 8293187: Store initialized Enum classes in AOTCache [v3]

Ashutosh Mehra asmehra at openjdk.org
Thu Sep 19 21:40:37 UTC 2024


On Thu, 19 Sep 2024 16:26:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Expanding on the above example, lets say A is aot- initialized, but B and C are not.
>> So this function should initialize only X not Y, is that correct? If so, then how does it prevent initialization of Y? It iterates through all the subgraph_object_klasses which includes both X and Y.
>
> The `subgraph_object_klasses` are built during assembly phase when each mirror is added to the cache. Note that we don't add the "real" mirror of the classes, but we add the scratch mirror:
> 
> 
> void HeapShared::archive_java_mirrors() {
>     ...
>     oop m = scratch_java_mirror(orig_k);
>     if (m != nullptr) {
>       Klass* buffered_k = ArchiveBuilder::get_buffered_klass(orig_k);
>       bool success = archive_reachable_objects_from(1, _default_subgraph_info, m);
> 
> 
> So the scratch mirrors of `B` and `C` will be empty when they are being archived.
> 
> Because `A` is marked as aot-initialized, we copy the fields of the "real" mirror of `A` into its scratch mirror. See `HeapShared::copy_aot_initialized_mirror()`. That's why we are able to add `X` into the subgraph_object_klasses (when `A`'s scratch mirror is scanned inside `archive_reachable_objects_from()`)

Oh I see! I was missing the point that scratch java mirrors are empty. So their clinit dependencies don't get recorded in subgraph_object_klasses. I should have seen that before. Sorry for dragging it.

The point that is bothering me is this code relies on the assumption that the default subgraph mainly consists of mirror objects, some of which may be aot-initialized, while others are emply. If in future we added other objects (not the mirror objects) to the graph, then this assumption would fail. But we don't have any check to protect against this.
Can we create a separate subgraph for aot-initialized mirror objects to record their clinit dependencies and process them here? That would make the code explicit in what it intends to do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1767631526


More information about the hotspot-dev mailing list