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

[Peter Levart]

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.
>>>>>>
>>>>
>