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

Kevin Walls kevin.walls at oracle.com
Tue Jan 19 11:53:01 UTC 2016


|
Hi Cheleswer, I think Martin is suggesting something like:
|

// Use a modest stack size, unless requested otherwise:
long stackSize = Boolean.getBoolean("processReaperUseDefaultStackSize") ? 0 : 32768;
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.



More information about the hotspot-runtime-dev mailing list