Openj9: Support for caching Hidden classes

[tajila]

Currently hidden classes are not cached. What will it take to add them to the SCC?

    bool isROMClassShareable() const {
        /*
         * Any of the following conditions prevent the sharing of a ROMClass:
         *  - classloader is not shared classes enabled
         *  - cache is full
         *  - the class is unsafe and isUnsafeClassSharingEnabled returns false (see the function isUnsafeClassShareable() for more details)
         *  - shared cache is BCI enabled and class is modified by BCI agent
         *  - shared cache is BCI enabled and ROMClass being store is intermediate ROMClass
         *  - the class is loaded from a patch path
         */
        if (isSharedClassesEnabled()
            && isClassLoaderSharedClassesEnabled()
            && (!isClassUnsafe() || isUnsafeClassSharingEnabled())
            && !(isSharedClassesBCIEnabled()
            && (classFileBytesReplaced() || isCreatingIntermediateROMClass()))
            && (LOAD_LOCATION_PATCH_PATH != loadLocation())
            && (!isClassHidden()) /* Need additional work if we want to share hidden class. Turn it off now. */
        ) {
            return true;
        } else {
            return false;
        }
    }

[tajila]

@hangshao0 We currently have support for caching anonclasses in the SCC. How does caching hidden classes differ from caching anonClasses? What are the technical challenges that need to be solved to enable this?

[hangshao0]

romaddress is appended to the name of Anon and hidden classes. The main issue here is that anon class are not in the hashtable but some hidden classes (defined with Option.STRONG) are in the hashtable (so that balanced GC can find them through hashtable iteration). The romaddress is unique in one JVMs instance, but it is not guaranteed to be unique in multiple JVM instances.

[tajila]

Okay, just to be clear are there two issues?

1)

main issue here is that anon class are not in the hashtable but some hidden classes (defined with Option.STRONG) are in the hashtable (so that balanced GC can find them through hashtable iteration)

2)

The romaddress is unique in one JVMs instance, but it is not guaranteed to be unique in multiple JVM instances.

For 1), I don't see why this would prohibit caching hidden classes, can you please elaborate.
For 2), Isn't this the same issue with anonClasses?

[hangshao0]

The issue is 2 different hidden classes could have the same hash key (same class name). Anon class are not in the hashtable, so it does not have this issue.

[gacholio]

Given that hidden classes can never be requested by name from the table, couldn't we do something to the hash computation for hidden classes so two different hidden classes of the same name don't hash the same? Perhaps hidden classes use their address instead of the name to hash?

[hangshao0]

From previous discussion in the email, we haven't decided whether to change balanced GC (to be the same as other policies) to walk the segment instead of hash table only. We added hidden classes to the hashtable as a temporarily solution to work around the balanced GC issue. If we decide the long term solution is to put the hidden class in the hashtable and do not change the GC side, then we need to change the hash table computation for hidden classes if we want to put them in the shared cache.

[tajila]

Perhaps hidden classes use their address instead of the name to hash?

IIRC a cached romClass isn't guaranteed to be mapped in the same address once it is restored from the cache @hangshao0 can you confirm?

Im thinking of this scenario:

JVM1 create hidden class -> A/0x01 (at address 0x01) and places it into the cache

JVM2 loads A/0x01 from SCC at address 0x02, it already has another A/0x01 at address 0x01

In this scenario searching with "0x01" will lead to conflicts

[tajila]

If we decide the long term solution is to put the hidden class in the hashtable

Yes, it is highly likely we will need hidden classes in the SCC long term since lambda forms in Java15+ make use of them. Having them in SCC will help the AOT story, which in turn will help startup perf.

[gacholio]

If we're talking about a classloader hash table, there's no need for the ROM class to be mapped to the same address in different VMs. The class name is never used external to the hashtable.

If the classes are going to be shared, the SCC also can't key on the name (A/0x01 could be entirely different classes in different VMs).

[hangshao0]

IIRC a cached romClass isn't guaranteed to be mapped in the same address.

The rom address is not guaranteed to be the same. For cached hidden class, we can take advantage of romaddress - cache header, which will be unique.

Yes, it is highly likely we will need hidden classes in the SCC.

I mean to put hidden classes in the SCC (I am not against putting them in the SCC), we can either 1) have balanced GC walk the segment, so hidden class do not need to be in the hashtable, so we don't have the hash key issue. Or 2) No GC change, keep hidden classes in the hashtable, change hashkey computation for hidden classes.

[hangshao0]

I am looking into this.

[hangshao0]

Working on a customer issue. Will come back to this issue after that.