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

[David Holmes]

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