Mark receivers of all constructors as oslots

[tajila]

Mark receivers of all constructors as oslots

Signed-off-by: Tobi Ajila [email protected]

[tajila]

@gacholio please review these changes

[gacholio]

jenkins test sanity zlinux jdk17

[DanHeidinga]

@tajila What's the rationale for this change? I'm curious if there's a spec change or a test case that shows this is a problem

[tajila]

@DanHeidinga

This relates to how we implement the J9_STACKWALK_HIDE_EXCEPTION_FRAMES in swalk. we compare the A0 slot with the exception object to determine if its an exception frame.

if (walkState->flags & J9_STACKWALK_HIDE_EXCEPTION_FRAMES) {
			J9ROMMethod * romMethod = J9_ROM_METHOD_FROM_RAM_METHOD(walkState->method);

			if (!(romMethod->modifiers & J9AccStatic)) {
				if (J9UTF8_DATA(J9ROMMETHOD_NAME(romMethod))[0] == '<') {
					if (*walkState->arg0EA == (UDATA) walkState->restartException) {
						return J9_STACKWALK_KEEP_ITERATING;
					}
				}
				walkState->flags &= ~J9_STACKWALK_HIDE_EXCEPTION_FRAMES;
			}
		}

If a GC occurs while we are doing super() calls all the way up the class chain, there is a possibility that the receiver will be moved. This is not a problem if all A0 slots are oslots, but if one of them is an islot it will not updated and the algorithm above fails.

We've always had this problem and it hasn't been an issue until JDK18 as the new reflection implementation makes use of the exception stack traces.

[DanHeidinga]

Thanks for explaining @tajila. Can I ask about this as well:

We've always had this problem and it hasn't been an issue until JDK18 as the new reflection implementation makes use of the exception stack traces.

the new reflection impl = using MHs - why is that using the exception stack traces?

[tajila]

the new reflection impl = using MHs - why is that using the exception stack traces?

Thats correct, the MH impl of reflection. The old reflection impl would treat all errors regarding input args as IllegalArgumentException, however with the new MH impl this is more difficult to detect as they show up as NPEs, classcastexceptions or WronmethodTypeExceptions. So the MH implementation catches all exceptions return from the MH and determines whether to re-throw as an illegalArg exception.

[DanHeidinga]

Thanks for explaining!

[DanHeidinga]

I understand we've already branched for Java 18 - should this be ported to the Java 18 branch as well? @tajila

[gacholio]

It's worth noting that this change is completely safe - we were already doing it for one constructor case, and the new object is necessarily already being kept alive by the caller of the constructor (since constructors are void return) so we're not artificially extended the lifetime of the object.