PING: RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero
Erik Gahlin
erik.gahlin at oracle.com
Fri Mar 8 15:37:28 UTC 2019
JFR imposes a limit on how many frames that can be recorded, set to 64
by default but configurable up to 2048 using -XX:FlightRecorderOptions,
so setting the value to 0 will still not mean all frames.
That said, if you still want to fix it. It may make sense to set
loop_max to INT_MAX, if MaxJavaStackTraceDepth is zero, i.e
int loop_max = MaxJavaStackTraceDepth == 0 ? INT_MAX :
MaxJavaStackTraceDepth * 2;
and avoid evaluating it for every frame. Even if the compiler is able to
hoist the comparison, it makes the code easier to read.
Thanks
Erik
> PING: Could you review it?
>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566
>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/
>
>
> If you have any questions, please tell me.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2019/02/27 22:46, Yasumasa Suenaga wrote:
>> Hi Erik,
>>
>> On 2019/02/27 22:30, Erik Gahlin wrote:
>>> Hi Yasumasa,
>>>
>>> Could you explain a little about the bug?
>>>
>>> Why should stack traces be collected if MaxJavaStackTraceDepth is
>>> set to 0.
>>
>> "0" in MaxJavaStackTraceDepth means all exception stack traces
>> will be shown.
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/72ce7dd54939/src/hotspot/share/runtime/globals.hpp#l1553
>>
>>
>> JDK-7179701 reports similar issue.
>> I think we can take similar approach for JDK-8219566.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>>> Thanks
>>> Erik
>>>
>>>> On 22 Feb 2019, at 07:48, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Please review this change:
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566
>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/
>>>>
>>>> JFR did not collect call stacks when MaxJavaStackTraceDepth is set
>>>> to zero.
>>>> This bug is similar to JDK-7179701.
>>>>
>>>> This change passed tests on submit repo and :jdk_jfr jtreg tests.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>
More information about the hotspot-jfr-dev
mailing list