-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8348853: Fold layout helper check for objects implementing non-array interfaces #24245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
2bf3f27
a77c397
daaaf9a
0467722
b1fb82a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3685,6 +3685,12 @@ bool TypeInterfaces::singleton(void) const { | |
| return Type::singleton(); | ||
| } | ||
|
|
||
| bool TypeInterfaces::has_non_array_interface() const { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Almost! return !TypeAryPtr::_array_interfaces->contains(this);Contains is about TypeInterfaces, that is set of interfaces. So I just need to check that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now I'm confused, isn't this what I proposed? I didn't check the exact syntax, I just wondered if the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, totally! It's just a detail difference. But there is another question: whether we still want There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For now, I just replaced the implementation of |
||
| assert(TypeAryPtr::_array_interfaces != nullptr, "How come Type::Initialize_shared wasn't called yet?"); | ||
|
|
||
| return !TypeAryPtr::_array_interfaces->contains(this); | ||
| } | ||
|
|
||
| //------------------------------TypeOopPtr------------------------------------- | ||
| TypeOopPtr::TypeOopPtr(TYPES t, PTR ptr, ciKlass* k, const TypeInterfaces* interfaces, bool xk, ciObject* o, int offset, | ||
| int instance_id, const TypePtr* speculative, int inline_depth) | ||
|
|
@@ -6197,6 +6203,19 @@ template <class T1, class T2> bool TypePtr::is_java_subtype_of_helper_for_instan | |
| return this_one->klass()->is_subtype_of(other->klass()) && this_one->_interfaces->contains(other->_interfaces); | ||
| } | ||
|
|
||
| bool TypeInstKlassPtr::might_be_an_array() const { | ||
| if (!instance_klass()->is_java_lang_Object()) { | ||
| // TypeInstKlassPtr can be an array only if it is java.lang.Object: the only supertype of array types. | ||
| return false; | ||
| } | ||
| if (interfaces()->has_non_array_interface()) { | ||
| // Arrays only implement Cloneable and Serializable. If we see any other interface, [this] cannot be an array. | ||
| return false; | ||
| } | ||
| // Cannot prove it's not an array. | ||
| return true; | ||
| } | ||
|
|
||
| bool TypeInstKlassPtr::is_java_subtype_of_helper(const TypeKlassPtr* other, bool this_exact, bool other_exact) const { | ||
| return TypePtr::is_java_subtype_of_helper_for_instance(this, other, this_exact, other_exact); | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we do the same by using
TypeKlassPtr::maybe_java_subtype_of(TypeAryKlassPtr::BOTTOM)and define aTypeAryKlassPtr::BOTTOMto be a static field for thearray_interfaces?AFAICT,
TypeKlassPtr::maybe_java_subtype_of()already covers that case so it would avoid some logic duplication. Also in the test above, maybe you could simplify the test a little but by removingtkls->isa_instklassptr()?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be
TypeAryKlassPtr::BOTTOM->maybe_java_subtype_of(tkls)rather than
tkls->maybe_java_subtype_of(TypeAryKlassPtr::BOTTOM)My reasoning: if
TypeAryKlassPtr::BOTTOMisjava.lang.Object + Cloneable + Serializableany array is a subtype of that. But so is any class implementing these interfaces. As well as as anyObjectimplementing more interfaces. But for these two last cases, we know they cannot be array, which is what we want to know: are we sure it's not an array, or could it be an array?But if we check if
tklsis a supertype ofjava.lang.Object + Cloneable + Serializable, then it has to be anObject(the most general class) and it implements a subset ofCloneableandSerializable. In this case, it can be an array. Iftklsis not a super-type ofjava.lang.Object + Cloneable + Serializable, there are 2 cases:is_instklassptr), and so a fortiori it can be an array type.java.lang.Object + Cloneable + Serializable. I.e. there is no typeTthat is not an array type, that is a super-type of at least one array type and that is not a super-type ofjava.lang.Object + Cloneable + Serializable(that is that is notjava.lang.Objector that implements at least another interface).In other words, our question is
(where
A <= BmeansA is a subtype of B) which is equivalent toWe can spare the call to
is_instklassptrby using a virtual method instead or probably other mechanisms, that's an implementation detail. But I think we need to distinguish cases: bothint[]andMyClass + Cloneable + Serializable + MyInterfaceare sub-types ofjava.lang.Object + Cloneable + Serializablebut for one, we can conclude it's definitely an array, and the other, it's definitely not. Without distinguishing cases, the only sound approximation would be to that that everything can be an array (both sub and super types ofjava.lang.Object + Cloneable + Serializable).Does that makes sense? Did I get something wrong? is the
BOTTOMnot what you had in mind?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, what I suggested doesn't work indeed.