Skip to content

Conversation

@harship04
Copy link

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.

@harship04 harship04 force-pushed the romcache branch 9 times, most recently from 19d1ee8 to 5f11894 Compare November 11, 2025 15:38
@babsingh babsingh requested a review from gacholio November 11, 2025 16:19
@gacholio
Copy link
Contributor

Waiting for the changes we discussed before review (but at a glance, looks good so far).

@harship04 harship04 force-pushed the romcache branch 3 times, most recently from 24bce23 to 18af487 Compare November 15, 2025 12:33
@harship04
Copy link
Author

@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));
Copy link
Contributor

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).

/* Always compute argument bits */
j9localmap_ArgBitsForPC0(romClass, romMethod, newInfo.argbits);

if (computeStackAndLocals && pc < (UDATA)J9_BYTECODE_SIZE_FROM_ROM_METHOD(romMethod)) {
Copy link
Contributor

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 */
Copy link
Contributor

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?

@gacholio
Copy link
Contributor

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.

@gacholio
Copy link
Contributor

The argbits do not seem to be being computed at all.

@harship04 harship04 force-pushed the romcache branch 2 times, most recently from 495e826 to b581cfd Compare November 25, 2025 20:26
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);
Copy link
Contributor

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.

Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants