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