Refuse to generate array class serialization records #19135
Conversation
|
Attn @mpirvu. |
The JITServer AOT cache will now refuse to generate class records for array ROM classes. This is relevant for clients running with -XX:+JITServerAOTCacheIgnoreLocalSCC - with this option disabled, the fact that array classes cannot be persisted in the local SCC acts as an implicit barrier to their ROM classes ever reaching the AOT cache. Without that option, the AOT cache must explicitly check that the given ROM class is not an array ROM class. In future, the AOT cache should be extended with support for array classes. For now, this change prevents excessive AOT cache deserialization failures from occurring at JITServer clients running with -XX:+JITServerAOTCacheIgnoreLocalSCC due to the nonsensical class records the cache previously generated for array classes. Signed-off-by: Christian Despres <despresc@ibm.com>
cjjdespres
force-pushed
the
disable-array-class-record-gen
branch
from
d161420 to
8729348
Compare
|
I did modify the log message that is emitted when the |
| // The current implementation cannot handle array ROM classes - the name must be recorded | ||
| // properly and the hash of the class must incorporate the array ROM class, the arity of the array, | ||
| // and the element ROM class. | ||
| if (J9ROMCLASS_IS_ARRAY(romClass)) |
There was a problem hiding this comment.
Excluding primitive array classes may be overkill. Their ROMClasses store their proper names which can be used to look them up at the client.
There was a problem hiding this comment.
I was worried that the romClass might be from an array class with primitive element type and arity greater than 1. I think that would result in a romClass with a name that looks like [I or something, but wouldn't have any arity information. Is that an issue?
There was a problem hiding this comment.
I suspect (but you might want to check) that multidimensional primitive array classes still use the [L ROMClass since they are arrays of references. By primitive arrays I meant specifically 1D arrays like [I or [Z, they use properly named ROMClasses. They are not stored in the SCC though, so I guess excluding them here should result in the same behaviour as before with the underlying local SCC.
There was a problem hiding this comment.
I think I'll leave it as-is just to keep the same behaviour as before when not ignoring the SCC.
|
jenkins test sanity plinuxjit,xlinuxjit,zlinuxjit,alinux64jit jdk17 |
|
On zlinux the tests passed, but then the harness couldn't cleanup. |
|
jenkins test sanity xlinuxjit,zlinuxjit jdk17 |
|
xlinux had the same infra issue: Since the tests themselves have passed am going to merge anyway. |
The JITServer AOT cache will now refuse to generate class records for array ROM classes. This is relevant for clients running with -XX:+JITServerAOTCacheIgnoreLocalSCC - with this option disabled, the fact that array classes cannot be persisted in the local SCC acts as an implicit barrier to their ROM classes ever reaching the AOT cache. Without that option, the AOT cache must explicitly check that the given ROM class is not an array ROM class.
In future, the AOT cache should be extended with support for array classes. For now, this change prevents excessive AOT cache deserialization failures from occurring at JITServer clients running with -XX:+JITServerAOTCacheIgnoreLocalSCC due to the nonsensical class records the cache previously generated for array classes.
Related: #18990