Re: 回复:Re: 回复:Re: A solution to detect the footprint of Java thread stack

Zhengyu Gu zgu at redhat.com
Wed Dec 16 12:54:18 UTC 2020


Hi,

I agree with David, I don't see a lot of benefits for adding warning zone.

I believe the feature can be achieved by utilizing existing NMT 
functionality as Thomas pointed out, either vs. JFR or jcmd, to report 
thread stack physical sizes (committed size), since they do not shrink, 
you get the idea the maximum space a thread used.

-Zhengyu


On 12/16/20 12:03 AM, David Holmes wrote:
> Adding back the mailing lists ...
> 
> Hi,
> 
> On 16/12/2020 1:00 pm, Yang Yi wrote:
>> ​Hi David,
>>
>> The purpose of this option is to warn rather than avoiding stack
>> overflow. It would tell users how much stack space they have been used
>> and what is the percentage of the stack footprint in the total. If the
>> ratio of stack footprint reaches - XX:StackWarningRatio=90 in many
>> iterations of the application, the user can make a judgment, whether to
>> increase the stack space to reduce the risk of StackOverflowError or
>> keep the current stack size to save memory as much as possible.
> 
> My concern is the cost:benefit ratio for this feature. It's code that 
> has to be added and maintained and may interact in unintended ways with 
> other features - like ReservedStackAccess. So to me I see the cost here 
> as moderate. The benefit seems very small to me. I don't recall ever 
> seeing a feature request for this, and I just searched for it. If people 
> were trying to size their applications in the way you suggest, or if 
> they wanted to do so, then I would have expected to see requests for 
> such functionality. At the moment this seems a solution in search of a 
> problem.
> 
> Just my opinion of course.
> 
> Cheers,
> David
> -----
> 
>>
>> Best,
>> Yang YI
>>
>>     ------------------------------------------------------------------
>>     发件人:David Holmes<david.holmes at oracle.com>
>>     日 期:2020年12月15日 15:26:56
>>     收件人:Yang Yi<qingfeng.yy at alibaba-inc.com>; HotSpot Open Source
>>     Developers<hotspot-dev at openjdk.java.net>;
>>     hotspot-jfr-dev<hotspot-jfr-dev at openjdk.java.net>
>>     主 题:Re: 回复:Re: A solution to detect the footprint of Java
>>     thread stack
>>
>>     Hi,
>>
>>     On 15/12/2020 5:02 pm, Yang Yi wrote:
>>      > Hi David,
>>      >
>>      > Thank you for your comments.
>>      >
>>      >
>>      
>> > How do you actually envisage people using this? This seems more of a
>>      >
>>      
>> > tuning option, but you can tune just as readily by adjusting -Xss in the 
>>
>>      >
>>      
>> > same manner you would set the warning ratio. I.e. you'd like to shrink
>>      >
>>      
>> > your stack usage but are not sure how small you can make it safely so
>>      >
>>      
>> > you can either just reduce -Xss and see if it works, or you can set the
>>      >
>>      
>> > warning ratio to give the same effective -Xss and see if you get a warning. 
>>
>>      >
>>      > Yes, we can indeed achieve similar goals by constantly adjusting
>>      > -Xss, but adjusting -Xss is generally a way to make the
>>     application work
>>      > again after StackOverflowError occurs. The purpose of
>>      > -XX:StackWarningRatio is to warn early before StackOverflowError
>>     occurs.
>>
>>     But the problem there is that triggering the warning does not 
>> indicate
>>     that a stackoverflow will in fact occur. It will only tell whether 
>> you
>>     used a given percentage of your stack, not how much you have actually
>>     used. So how does this help you avoid stackoverflow? If you used the
>>     warning to increase -Xss without ever encountering stackoverflow then
>>     you are just wasting memory and potentially reducing the number of
>>     threads you can support.
>>
>>     Cheers,
>>     David
>>
>>
>>      > Based on my experience and observation, many developers use the
>>     default
>>      > value of ThreadStackSize(the default value of is 1M on
>>     linux_x86), they
>>      > will not adjust the value of this option unless a stack overflow
>>     occurs.
>>      > With the iterative development of the application, the size of
>>     the stack
>>      > may no longer meet the demand. It's helpful to warn about
>>     insufficient
>>      > stack space earlier in case of hurriedly troubleshooting and
>>     adjusting
>>      > the -Xss when the application throws StackOverflowError in the
>>      > production environment.
>>      >
>>
>>
>>      >
>>      > > The flag would need to be diagnostic rather than full product.
>>      >
>>      > Accept.
>>      >
>>      > Best,
>>      > Yang Yi
>>      >
>>      > ------------------------------------------------------------------
>>      > 发件人:David Holmes<david.holmes at oracle.com>
>>      > 日 期:2020年12月15日 13:24:54
>>      > 收件人:Yang Yi<qingfeng.yy at alibaba-inc.com>; HotSpot Open Source
>>      > Developers<hotspot-dev at openjdk.java.net>;
>>      > hotspot-jfr-dev<hotspot-jfr-dev at openjdk.java.net>
>>      > 主 题:Re: A solution to detect the footprint of Java thread 
>> stack
>>      >
>>      > Hi Yang Yi,
>>      >
>>      > On 14/12/2020 3:03 pm, 杨易(青风) wrote:
>>      > > Hi all,
>>      >
>>      
>> > We occasionally get stack overflow errors if the application has too many deep callings. The usual solution is to increase -Xss, but there is no guiding opinion telling us in advance that the thread stack space is not enough. This patch attempts to address this issue. It introduces a new stack zone(warning_zone) for Hotspot VM, which can be used to detect whether the footprint ratio of the thread stack has reached the watermark set by the user. 
>>
>>      > >
>>      > > The current stack layout is as follows:
>>      >
>>      
>> > stack_base                                                                                    stack_end 
>>
>>      >
>>      
>> > --------------------------------------------------------------------------------------------------------------------------- 
>>
>>      >
>>      
>> > |        |   shadow zone |                   warning zone(added)                   | reserved zone | yellow zone | red zone | 
>>
>>      >
>>      
>> > --------------------------------------------------------------------------------------------------------------------------- 
>>
>>      >
>>      
>> >           ^rsp                   |<-StackWarningRatio % of available stack-> 
>>
>>      > >
>>      >
>>      
>> > Users can set the option -XX:StackWarningRatio=0 to turn off this feature(which is also the default value) and there will be no warning zone, the stack layout is the same as usual. 
>>
>>      >
>>      
>> > If the user sets -XX:StackWarningRatio to 50, the VM will protect 50% of the available stack space(let all = available+reserved+yellow+red;) as stack warning zone. When the footprint of available stack space reaches 50%, that is, when the application accesses the stack warning zone, the sigsegv signal will be triggered, and then the signal handler will warn this access in some ways(e.g. send the JFR event, logging) and resume current execution. As a prototype, this feature is only implemented on x86_posix, it can be implemented on more platforms as needed. 
>>
>>      > >
>>      >
>>      
>> > Could anyone give some suggestions? If you think this is a useful feature, I will file an issue and support it on all platforms. Looking forward to your comments. 
>>
>>      >
>>      > 
>> How do you actually envisage people using this? This seems more of a
>>      >
>>     
>> tuning option, but you can tune just as readily by adjusting -Xss in the
>>      >
>>      >
>>     
>> same manner you would set the warning ratio. I.e. you'd like to shrink
>>      > 
>> your stack usage but are not sure how small you can make it safely so
>>      >
>>     
>> you can either just reduce -Xss and see if it works, or you can set the
>>      >
>>     
>> warning ratio to give the same effective -Xss and see if you get a warning. 
>>
>>      >
>>      > The flag would need to be diagnostic rather than full product.
>>      >
>>      > Cheers,
>>      > David
>>      >
>>      >
>>      
>> > Patch: https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea 
>>
>>      > > Diff: https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e
>>      > >
>>      > > Best,
>>      > > Yang Yi
>>      > >
>>      >
>>



More information about the hotspot-dev mailing list