Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement class relationship recording and validating #7089
Store class relationships to delay verifying class compatibility (child, parent relationships) until triggered by class loading, instead of verifying compatibility upfront. Validate relationships for a class during class initialization, throwing a Verify Error if validation fails.
Testing will be added in a future PR.
Store class relationships (child and its superclass/superinterface relationships) in a hash table (saved in the class loader) instead of loading the classes and verifying them upfront. Each child (source class) table entry contains a list of its parents (target classes), with parent nodes being added as they are encountered. Enable feature using `-XX:+ClassRelationshipVerifier`. Disable feature using `-XX:-ClassRelationshipVerifier`. Throw error if `-Xfuture` is used with `-XX:+ClassRelationshipVerifier`. Note that `-Xverify:all` also enables `-Xfuture`. Signed-off-by: Sharon Wang <email@example.com>
Currently, the code always adds the relationship even if it has already been added. This can lead to very long lists of parents which delays processing them. The insight here is that by keeping the list in the order of the classname length, we can more quickly weed out duplicates as we only need to walk the list until there is a longer name, or the same name already present, before inserting. Additionally, avoid the parent node allocation until we know we’re adding something to the list. Signed-off-by: Sharon Wang <firstname.lastname@example.org>
When a class is being initialized, validate that it holds the expected relationship with each parent in its list. Free memory for the child hash table entry and parent nodes once validation is complete. Throw java/lang/VerifyError if validation of class relationships fails. Note that this validation check can be moved to any point prior to a class being made available. Signed-off-by: Sharon Wang <email@example.com>
Instead of allocating a parent node for Throwable, set a bit in the childEntry flags J9RELATIONSHIP_PARENT_IS_THROWABLE. During validation, check if the bit is set. If so, retrieve the Throwable class and check that it is a superclass of the child. Throwable seems to occur frequently as a parent class, so this change will avoid the duplicate memory allocations done for Throwable. Signed-off-by: Sharon Wang <firstname.lastname@example.org>