RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing.

[Severin Gehwolf]

On Thu, 2015-07-30 at 14:48 +0200, Volker Simonis wrote:
> On Thu, Jul 30, 2015 at 1:28 PM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > On Thu, 2015-07-30 at 10:46 +0200, Volker Simonis wrote:
> >> Why can't you simply use:
> >>
> >>   --with-boot-jdk-jvmargs specify JVM arguments to be passed to all java
> >>                           invocations of boot JDK, overriding the default
> >>                           values, e.g --with-boot-jdk-jvmargs="-Xmx8G
> >>                           -enableassertions"
> >>
> >> with the corresponding stack settings?
> >
> > See my earlier response to David. I'll do some more tests, but it didn't
> > work for me.
> >
> 
> So you are saying the StackOverflow may come from a thread which has
> specified its own stack size at construction time and therefore the
> default stack size settings are ignored. But I did a fast grep through
> the jdk/ and langtools/ repository and couldn't find any occurrence of
> such a 4-argument Thread constructor (i.e. "Thread(ThreadGroup group,
> Runnable target, String name, long stackSize)").

Yes. Here is one occurrence
(src/java.base/share/classes/java/lang/ProcessHandleImpl.java):

final class ProcessHandleImpl implements ProcessHandle {

    /**
     * The thread pool of "process reaper" daemon threads.
     */
    private static final Executor processReaperExecutor =
            doPrivileged((PrivilegedAction<Executor>) () -> {

                ThreadGroup tg = Thread.currentThread().getThreadGroup();
                while (tg.getParent() != null) tg = tg.getParent();
                ThreadGroup systemThreadGroup = tg;

                ThreadFactory threadFactory = grimReaper -> {
                    // Our thread stack requirement is quite modest.
                    Thread t = new Thread(systemThreadGroup, grimReaper,
                            "process reaper", 32768);


I've just tried a clean build with:
--with-boot-jdk-jvmargs="-XX:ThreadStackSize=2240
-XX:VMThreadStackSize=1600" specified to configure. It
stack-overflowed :(

> If a normal thread doesn't honor the -XX:ThreadStackSize settings I'd
> consider that a bug and fix that one first.

By fixing it you mean in jdk or hotspot code? Any suggestions?

Thanks,
Severin