RFR (S) 7179701: MaxJavaStackTraceDepth of zero is not handled correctly/consistently in the VM
David Holmes
david.holmes at oracle.com
Tue Jan 30 01:02:07 UTC 2018
Hi Coleen,
Wow this one is a blast from the past! :)
On 30/01/2018 9:54 AM, coleen.phillimore at oracle.com wrote:
> Summary: Value of zero means unlimited stack trace. If you want no
> stack trace, use -XX:-StackTraceInThrowable
>
> I think I broke this with rework to Throwable fill_in_stack_trace.
> Tested with jvmti, jdi and stack stress tests. Also tested manually
> with version of the new test with kill -3 to test the thread.cpp code.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/7179701.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-7179701
Overall looks fine. One nit ...
src/hotspot/share/classfile/javaClasses.cpp
This looks really awkward for a loop condition:
1971 for (frame fr = thread->last_frame(); max_depth > 0 ? max_depth
!= total_count : true;) {
how about changing:
1936 int max_depth = MaxJavaStackTraceDepth;
to
1936 int max_depth = MaxJavaStackTraceDepth > 0 ?
MaxJavaStackTracedepth : INT_MAX;
instead? Or, in the style of the other changes:
1971 for (frame fr = thread->last_frame();
max_depth == 0 || max_depth < total_count;) {
?
---
src/hotspot/share/prims/forte.cpp
I'm wondering what tests actually hit this code?
Thanks,
David
> Thanks,
> Coleen
More information about the hotspot-runtime-dev
mailing list