Approved.
As author of the small stack size for the reaper thread, I'm sorry
it's caused so much trouble.
But as always, the proper solution is to fix the java runtime so that
fixed allocations like this are unnecessary.
hard: stack size should not include native overhead like shadow pages.
Switching to a debug build should not cause SOE.
harder: banish SOE in pure java code entirely by loomishly moving
continuations to a larger stack.
On Wed, Jul 8, 2020 at 1:54 PM Roger Riggs <roger.ri...@oracle.com> wrote:
>
> Please reveiw a change to increase the size of the Process Reaper stack
> for debug builds.
> This intermittent issue can be traced to the stack shadow page size
> being larger
> in debug builds than in release builds. The problem has only been
> spotted in debug builds.
>
> diff a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> @@ -85,12 +85,16 @@
> doPrivileged((PrivilegedAction<Executor>) () -> {
>
> ThreadGroup tg = Thread.currentThread().getThreadGroup();
> while (tg.getParent() != null) tg = tg.getParent();
> ThreadGroup systemThreadGroup = tg;
> +
> + // For a debug build, the stack shadow zone is larger;
> + // Increase the total stack size to avoid potential stack
> overflow.
> + int debugDelta =
> "release".equals(System.getProperty("jdk.debug")) ? 0 : 8192;
> final long stackSize =
> Boolean.getBoolean("jdk.lang.processReaperUseDefaultStackSize")
> - ? 0 : REAPER_DEFAULT_STACKSIZE;
> + ? 0 : REAPER_DEFAULT_STACKSIZE + debugDelta;
>
> ThreadFactory threadFactory = grimReaper -> {
> Thread t = new Thread(systemThreadGroup, grimReaper,
> "process reaper", stackSize, false);
> t.setDaemon(true);
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-process-stackoverflow-8217475/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8217475
>
> Thanks, Roger
>
