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

[Volker Simonis]

On Thu, Jul 30, 2015 at 3:14 PM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> 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);
>

OK, I've looked in the jdk8 sources and ProcessHandle is quite new in
jdk9 (since about a month or so). Are you sure this is the root case
of your problem?

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

Yes, but which thread? What's the stack trace?

Do you see the stack arguments in the command line which produced the
stack overflow (i.e. are they correctly propagated by the build
system)?

Does this occur for the initial build (with a jdk8 bootstrap jdk) or
only in the self build with jdk9?

If you have a reproducer, can you run it with "-XX:PrintFlagsFinal" to
see the final flag settings?

And could you get a thread dump from the reproducer to see the actual
stack size of the offending thread?

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

I mean in the hostspot code. But of coarse only if the above tests
show that the settings are not honored by the VM.

> Thanks,
> Severin
>