RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

[Roger Riggs]

Hi Peter,

David, on serviceability-dev [1], was of the opinion that a simple 
increase would be too temporary.

Roger

[1]


On 1/20/2016 10:19 AM, Peter Levart wrote:
> Hi,
>
> On 01/20/2016 03:09 PM, Roger Riggs wrote:
>> Hi David,
>>
>> I read an old description;  I was expecting the value of the property 
>> to be the stack size for the reaper.
>> That would allow more control and less waste when it needed to be 
>> overridden.
>> Set it to zero if the default size is desired.
>>
>> Roger
>
> Wouldn't it be more appropriate that for modest use there would be no 
> need to specify a system property. By modest use, I mean starting just 
> a few sub-processes. So if we add 32k (or whatever the max. possible 
> overhead of TLS is) to the existing 32k, that should be the default 
> for reaper thread. If one needs to make it even smaller to accommodate 
> for exceptional use, he can then use this new system property.
>
> Regards, Peter
>
>>
>> On 1/20/2016 12:05 AM, David Holmes wrote:
>>> On 20/01/2016 8:39 AM, David Holmes wrote:
>>>> On 20/01/2016 12:50 AM, Roger Riggs wrote:
>>>>> Hi,
>>>>>
>>>>> How about "jdk.process.reaperStackSize".
>>>>
>>>> Based on some internal discussion that seems appropriate to me ...
>>>
>>> Except of course that the property is just a boolean not a size. :) 
>>> So jdk.process.reaperUsesdefaultStackSize seems appropriate.
>>>
>>> David
>>>
>>>>> It will need a CCC .
>>>>
>>>> ... and if not then the CCC will show the way. :)
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>> On 1/19/16 7:10 AM, David Holmes wrote:
>>>>>> On 19/01/2016 9:53 PM, Kevin Walls wrote:
>>>>>>> |
>>>>>>> Hi Cheleswer, I think Martin is suggesting something like:
>>>>>>> |
>>>>>>>
>>>>>>> // Use a modest stack size, unless requested otherwise:
>>>>>>> long stackSize =
>>>>>>> Boolean.getBoolean("processReaperUseDefaultStackSize") ? 0 : 32768;
>>>>>>
>>>>>> Someone from core-libs needs to chime on what the appropriate
>>>>>> namespace for such a property would be.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thread t = new Thread(systemThreadGroup, grimReaper, "process
>>>>>>> reaper", stackSize);
>>>>>>>
>>>>>>> |||
>>>>>>> If that tests OK for you, it may be the way we can go ahead with 
>>>>>>> the
>>>>>>> point fix for this.
>>>>>>>
>>>>>>> Regards
>>>>>>> Kevin
>>>>>>> |
>>>>>>> On 18/01/2016 16:52, Martin Buchholz wrote:
>>>>>>>> Historical note - I never liked having a reaper thread for each
>>>>>>>> subprocess, but no other reliable implementation is known. 
>>>>>>>> Given the
>>>>>>>> potential for many reaper threads, I at least wanted to keep the
>>>>>>>> memory waste low.
>>>>>>>>
>>>>>>>> On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu
>>>>>>>> <cheleswer.sahu at oracle.com>  wrote:
>>>>>>>>
>>>>>>>>> +                   Thread t = null;
>>>>>>>>> +                   if
>>>>>>>>> (Boolean.getBoolean("processReaperUseDefaultStackSize")) {
>>>>>>>>> +                       t = new Thread(systemThreadGroup, 
>>>>>>>>> grimReaper,
>>>>>>>>> "process reaper");
>>>>>>>>> +                    } else {
>>>>>>>>> +                       // Our thread stack requirement is quite
>>>>>>>>> modest.
>>>>>>>>> +                       t = new Thread(systemThreadGroup, 
>>>>>>>>> grimReaper,
>>>>>>>>> "process reaper", 32768);
>>>>>>>>> +                    }
>>>>>>>> If we do end up using this strategy, cleaner would be to use
>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-java.lang.String-long- 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> stackSize - the desired stack size for the new thread, or zero to
>>>>>>>> indicate that this parameter is to be ignored.
>>>>>>>
>>>>>
>>
>