-
Notifications
You must be signed in to change notification settings - Fork 776
Implement ROMMethodInfo caching support and stack walker integration #22918
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
base: master
Are you sure you want to change the base?
Conversation
19d1ee8 to
5f11894
Compare
|
Waiting for the changes we discussed before review (but at a glance, looks good so far). |
24bce23 to
18af487
Compare
|
@gacholio , could you please review the PR |
runtime/vm/swalk.c
Outdated
| MARK_SLOT_AS_OBJECT(walkState, (j9object_t*) &(methodFrame->specialFrameFlags)); | ||
| walkState->method = methodFrame->method; | ||
| if (NULL != walkState->method) { | ||
| initializeBasicROMMethodInfo(walkState, J9_ROM_METHOD_FROM_RAM_METHOD(walkState->method)); |
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 don't think there should be any remaining callers of the basic init code (other than internally in mapcache.cpp) - they should all be replaced with the new ROM method call (other than the one for a bytecoded PC of course).
runtime/stackmap/mapcache.cpp
Outdated
| /* Always compute argument bits */ | ||
| j9localmap_ArgBitsForPC0(romClass, romMethod, newInfo.argbits); | ||
|
|
||
| if (computeStackAndLocals && pc < (UDATA)J9_BYTECODE_SIZE_FROM_ROM_METHOD(romMethod)) { |
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.
Please bracket the second clause. In fact, why is this necessary? I think we can assume a running PC is withing the bytecode range of its method.
| NULL); | ||
| } | ||
|
|
||
| /* Copy metadata */ |
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.
Should this not be a call to the basic init code?
|
Looks good in general. When computing the maps, you are not checking the size, checking for failure, or setting the bits indicating that the maps have been cached. |
|
The argbits do not seem to be being computed at all. |
495e826 to
b581cfd
Compare
| J9ROMMethod *romMethod = J9_ROM_METHOD_FROM_RAM_METHOD(method); | ||
|
|
||
| /* Use the ROMMethod pointer plus bytecode offset as key */ | ||
| void *key = (void *)((uintptr_t)J9_BYTECODE_START_FROM_ROM_METHOD(romMethod) + (uintptr_t)osrFrame->bytecodePCOffset); |
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.
This is problematic as it reads the ROM method before checking the cache. Perhaps we need to store the actual PC in the OSR frame. We could then derive the offset in the cache miss case.
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.
Actually, I'm wrong. The macro does simple addition and does not touch the ROM method memory itself.
Implements a unified ROM method caching mechanism for consolidating ROM method metadata. Updates stack walking to use the cached information instead of repeated metadata lookups.