-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8329750: Change Universe functions to return more specific Klass* types #18652
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
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 |
|---|---|---|
|
|
@@ -368,7 +368,7 @@ Klass* SystemDictionary::resolve_array_class_or_null(Symbol* class_name, | |
| } | ||
| } else { | ||
| k = Universe::typeArrayKlass(t); | ||
| k = TypeArrayKlass::cast(k)->array_klass(ndims, CHECK_NULL); | ||
| k = k->array_klass(ndims, CHECK_NULL); | ||
|
Comment on lines
370
to
+371
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. I assume the cast was an attempt to de-virtualize the array_klass() call, so it is better not to use Klass* here. 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. My experience is that these type of casts doesn't make the compiler devirtualize the calls. I tried it now and verified that both with and without the cast we still get the virtual call. You typically need to tell the compiler what function it should be using. (I played around a lot with this when writing the devirtualization layer for the oop_iterate/OopIterateClosure code.) I tested writing the code above as 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. OK, I guess the compiler needs to be conservative in case TypeArrayKlass has a subclass. 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. this looks puzzling. Why are there two array_klass calls now? Add short comments to explain. 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. I sort of see now but am getting squint lines. It's not important for performance to eliminate a virtual call here. 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. Hmm. Having two 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. Oh good because I was going to need a lot more coffee to understand why there was a second call. Thanks. 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. Why devirtualize elsehwere but not here? Maybe it's not a big deal. 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. Or to put it another way, what's the advantage of using |
||
| } | ||
| return k; | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.