Implement ROMMethodInfo caching support and stack walker integration #22918
Conversation
harship04
force-pushed
the
romcache
branch
9 times, most recently
from
19d1ee8 to
5f11894
Compare
|
Waiting for the changes we discussed before review (but at a glance, looks good so far). |
harship04
force-pushed
the
romcache
branch
2 times, most recently
from
b9285e6 to
24bce23
Compare
Signed-off-by: Graham Chapman <[email protected]>
|
@gacholio , could you please review the PR |
| 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.
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).
| /* 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.
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.
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. |
2 participants
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.