RFR (S) 7179701: MaxJavaStackTraceDepth of zero is not handled correctly/consistently in the VM

[coleen.phillimore at oracle.com]

On 1/29/18 8:02 PM, David Holmes wrote:
> Hi Coleen,
>
> Wow this one is a blast from the past! :)

Yeah, cleaning up some backlog ...
>
> 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;) {

I'll change it to like this, which does look nicer:
   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?
>

I couldn't find any, and don't really know how to test this code, which 
is why I ran a lot of serviceability tests.

Thanks,
Coleen

> Thanks,
> David
>
>
>> Thanks,
>> Coleen