RFR 9: 8086278 : java/lang/ProcessHandle/TreeTest.java failed - ProcessReaper StackOverflowException
Please review an increase in the default stack size of the Process reaper thread to 48K from 32k. Some tests with various VM arguments are failing intermittently. The failures are not reproducible. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reaper-stack-8086278/ Issue: https://bugs.openjdk.java.net/browse/JDK-8086278 Thanks, Roger
On 13/04/16 16:42, Roger Riggs wrote:
Please review an increase in the default stack size of the Process reaper thread to 48K from 32k. Some tests with various VM arguments are failing intermittently. The failures are not reproducible.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reaper-stack-8086278/
Seems reasonable. While you are there, is there any reason why the reaper cannot use the overloaded Thread constructor to suppress inheriting inheritable-thread-local initial values? -Chris.
Issue: https://bugs.openjdk.java.net/browse/JDK-8086278
Thanks, Roger
Hi Chris, On 4/13/2016 12:02 PM, Chris Hegarty wrote:
On 13/04/16 16:42, Roger Riggs wrote:
Please review an increase in the default stack size of the Process reaper thread to 48K from 32k. Some tests with various VM arguments are failing intermittently. The failures are not reproducible.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reaper-stack-8086278/
Seems reasonable.
While you are there, is there any reason why the reaper cannot use the overloaded Thread constructor to suppress inheriting inheritable-thread-local initial values? ok, done.
I also moved the reading of the system property to the once only code instead of inside the thread factory. Nested lambda make it harder to see what is executed when. Thanks, Roger
-Chris.
Issue: https://bugs.openjdk.java.net/browse/JDK-8086278
Thanks, Roger
On 13/04/16 18:11, Roger Riggs wrote:
Hi Chris,
On 4/13/2016 12:02 PM, Chris Hegarty wrote:
On 13/04/16 16:42, Roger Riggs wrote:
Please review an increase in the default stack size of the Process reaper thread to 48K from 32k. Some tests with various VM arguments are failing intermittently. The failures are not reproducible.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reaper-stack-8086278/
Seems reasonable.
While you are there, is there any reason why the reaper cannot use the overloaded Thread constructor to suppress inheriting inheritable-thread-local initial values? ok, done.
I also moved the reading of the system property to the once only code instead of inside the thread factory. Nested lambda make it harder to see what is executed when.
Looks ok. -Chris.
If you're actually seeing faiures with 32k, then 48k is too conservative. I suggest 128k. I tried once to increase the limit to 64k, but without a failing test it didn't get any support. The presence of native thread local variables is the biggest reason for blowing the stack; no limit is actually safe! That's a deep hotspot/glibc problem. On Wed, Apr 13, 2016 at 8:42 AM, Roger Riggs <Roger.Riggs@oracle.com> wrote:
Please review an increase in the default stack size of the Process reaper thread to 48K from 32k. Some tests with various VM arguments are failing intermittently. The failures are not reproducible.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reaper-stack-8086278/
Issue: https://bugs.openjdk.java.net/browse/JDK-8086278
Thanks, Roger
The change itself is fine. On Wed, Apr 13, 2016 at 1:08 PM, Martin Buchholz <martinrb@google.com> wrote:
If you're actually seeing faiures with 32k, then 48k is too conservative. I suggest 128k.
I tried once to increase the limit to 64k, but without a failing test it didn't get any support.
The presence of native thread local variables is the biggest reason for blowing the stack; no limit is actually safe! That's a deep hotspot/glibc problem.
On Wed, Apr 13, 2016 at 8:42 AM, Roger Riggs <Roger.Riggs@oracle.com> wrote:
Please review an increase in the default stack size of the Process reaper thread to 48K from 32k. Some tests with various VM arguments are failing intermittently. The failures are not reproducible.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reaper-stack-8086278/
Issue: https://bugs.openjdk.java.net/browse/JDK-8086278
Thanks, Roger
HI Martin, I thought if I overshot, I'd get some push back on too big stack sizes. I'll use 128k and see. Thanks, Roger On 4/13/2016 4:09 PM, Martin Buchholz wrote:
The change itself is fine.
On Wed, Apr 13, 2016 at 1:08 PM, Martin Buchholz <martinrb@google.com> wrote:
If you're actually seeing faiures with 32k, then 48k is too conservative. I suggest 128k.
I tried once to increase the limit to 64k, but without a failing test it didn't get any support.
The presence of native thread local variables is the biggest reason for blowing the stack; no limit is actually safe! That's a deep hotspot/glibc problem.
On Wed, Apr 13, 2016 at 8:42 AM, Roger Riggs <Roger.Riggs@oracle.com> wrote:
Please review an increase in the default stack size of the Process reaper thread to 48K from 32k. Some tests with various VM arguments are failing intermittently. The failures are not reproducible.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reaper-stack-8086278/
Issue: https://bugs.openjdk.java.net/browse/JDK-8086278
Thanks, Roger
participants (3)
-
Chris Hegarty
-
Martin Buchholz
-
Roger Riggs