8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack #1724
Method handle logging is broken in fastdebug builds. Problem is that os::current_frame() doesn't return the right frame in fastdebug builds.
The text was updated successfully, but these errors were encountered:
the fix is, as you commented too, a hack.
I think that (A) os::current_stack_pointer() is inlined into os::current_frame() with optimized builds (all except slowdebug) so for the slowdebug build (_NMT_NOINLINE_ is defined) the sender of the sender of topframe should be returned. For optimized builds just the sender of topframe should be returned (see implementation on s390).
I think furthermore that (B) the compilers on PPC64 don't use a tail call in NativeCallStack::NativeCallStack() so one more frame needs to be skipped.
I'd imagine a fix like the following.
I tested it successfully on Linux and AIX with the fastdebug build (RedefineClasses.java with -XX:+Verbose).
What do you think?
Tests succeeded also in slowdebug and release on Linux/PPC64 (-XX:+Verbose is not supported in release though).
test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java failed in slowdebug on AIX. But that's no showstopper, is it?
Thanks for your proposal. I'll try it.
If it fails without this change, it'd be no regression and hence ok.
That's a known xlc bug. Workaround:
we can even do without NMT_NOINLINE.
My manual tests succeed with this on aix and linuxppc64le, except for the slowdebug build on aix where test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java fails with and without the fix.
Currently I don't understand why the result of __builtin_frame_address(0) has to
I don't understand that, either. Seems like it was implemented by trial and error. I think trying to predict the C++ compiler's inlining is a terrible design, but it's only used by non-critical code like NMT stack traces, so we can focus on more critical issues.
We could use __builtin_frame_address(1) and remove the dereferencing. I think we should use that also in os::current_stack_pointer(). What do you think?
Anyway, I like your proposal. Would you mind creating a PR for jdk16 as we need it there? I'm closing this one.
Me neither. I found it in the implementation for x86_64 and learned that xlC supports it as well.
According to the documentation (https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html) this is not really safe.
So I wouldn't do it.
We could still use it in os::current_stack_pointer() and in os::current_frame().
That's fine for me.