Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #27702 > unrolled thread

[opinion] javac's default stack space

Back to article view | Back to comp.lang.java.programmer

Contents

  [opinion] javac's default stack space Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-09 14:25 +0000
    Re: [opinion] javac's default stack space Robert Klemme <shortcutter@googlemail.com> - 2014-03-10 18:33 +0100
      Re: [opinion] javac's default stack space Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-10 21:02 +0000
        Re: [opinion] javac's default stack space Robert Klemme <shortcutter@googlemail.com> - 2014-03-11 23:19 +0100
      Re: [opinion] javac's default stack space "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-03-11 19:56 +0000
        Re: [opinion] javac's default stack space Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-12 00:53 +0000
          Re: [opinion] javac's default stack space Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-23 20:37 +0000
    Re: [opinion] javac's default stack space Arne Vajhøj <arne@vajhoej.dk> - 2014-03-10 21:21 -0400
      Re: [opinion] javac's default stack space Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-11 14:16 +0000
        Re: [opinion] javac's default stack space Arne Vajhøj <arne@vajhoej.dk> - 2014-03-11 18:05 -0400
          Re: [opinion] javac's default stack space Robert Klemme <shortcutter@googlemail.com> - 2014-03-11 23:22 +0100
            Re: [opinion] javac's default stack space Arne Vajhøj <arne@vajhoej.dk> - 2014-03-11 19:50 -0400

#27702 — [opinion] javac's default stack space

I recently got some Java sources that caused "javac" on
my machine (Linux, Java 1.7, 32bit) to run out of stack
space, while compiling fine on AIX, Java 1.7, 64bit.

I then played with option -J-Xss# and a couple of values
for #, and found that up to about 350k it busted, while
with 360k or more it compiled just fine. My actual problem
is thus solved, but now I'm wondering...

While 32bit platforms themselves may almost be considered
as relicts from last millennium (ok: last decade), even
back then I'd have expected that allowing half a megabyte
for stack wouldn't have been considered overly wasteful.

Has anyone else run into javac's default stack size limit?

Does anyone else have any insight about what features of 
Java sources are likely culprits for stack usage peaks?

[toc] | [next] | [standalone]

#27714

On 09.03.2014 15:25, Andreas Leitgeb wrote:

> Has anyone else run into javac's default stack size limit?

Never.

> Does anyone else have any insight about what features of
> Java sources are likely culprits for stack usage peaks?

Can't you identify that from the source where it bails out?  Otherwise 
anything which requires recursion to process.  That might happen during 
parsing of deeply nested structures.  That is just a guess though.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#27717

Robert Klemme <shortcutter@googlemail.com> wrote:
> On 09.03.2014 15:25, Andreas Leitgeb wrote:
>> Has anyone else run into javac's default stack size limit?
> Never.

Just to be sure: are you also working with a *32bit* install of
Oracle's Java 1.7?  (*)

>> Does anyone else have any insight about what features of
>> Java sources are likely culprits for stack usage peaks?
> Can't you identify that from the source where it bails out?

With the appropriate option the problem itself has vanished,
so I'm probably not going to invest much more time into it.

If there is indeed any academic interest for research (or if I
find I can't sleep well until I research it further), then I'll
place some errors in the code, and trace compilation progress.
If Ι actually find the sore spot I'd post a followup, but don't 
hold your breath... ;)

Thanks for your answer.

PS: (*) the 64bit machine was an AIX, and it was IBM's
  Java implementation running there rather than Oracle's,
  which might (besides the bit-ness) be another possible
  reason for the Stack-Overflow not to have happened there.

[toc] | [prev] | [next] | [standalone]

#27732

On 03/10/2014 10:02 PM, Andreas Leitgeb wrote:
> Robert Klemme <shortcutter@googlemail.com> wrote:
>> On 09.03.2014 15:25, Andreas Leitgeb wrote:
>>> Has anyone else run into javac's default stack size limit?
>> Never.
>
> Just to be sure: are you also working with a *32bit* install of
> Oracle's Java 1.7?  (*)

Both - even on the same source.  I also once in a while compile with 
Java 6 (32 and 64 bit).  And in the past I almost exclusively used Java 
5 and 6 32 bit versions.  I cannot recall any instance where a stack 
overflow during compilation happened in javac.  Maybe it's not your Java 
but the OS default for stack size.

>>> Does anyone else have any insight about what features of
>>> Java sources are likely culprits for stack usage peaks?
>> Can't you identify that from the source where it bails out?
>
> With the appropriate option the problem itself has vanished,
> so I'm probably not going to invest much more time into it.

Too bad you are not so curios. :-)

> If there is indeed any academic interest for research (or if I
> find I can't sleep well until I research it further), then I'll
> place some errors in the code, and trace compilation progress.
> If Ι actually find the sore spot I'd post a followup, but don't
> hold your breath... ;)
>
> Thanks for your answer.

You're welcome.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#27730

Robert Klemme wrote:

> > Does anyone else have any insight about what features of
> > Java sources are likely culprits for stack usage peaks?
>
> Can't you identify that from the source where it bails out?  Otherwise
> anything which requires recursion to process.  That might happen during
> parsing of deeply nested structures.

Agreeing that the most likely culprit is some very[-very-very] deeply nested 
syntactic construction, I'd suggest that the most likely causes are: machine 
generated-code, and/or exuberant use of the "fluid" style -- you know the one:
    someObject
        .aaa()
        .aab()
        .aac()
        .aad()
    ...several pages later...
        .zzx()
        .zzy()
        .zzz()
        ;

In the absence of further info, I bet on machine-generated code.

(It also depends on the parsing technology, and how that tech is applied to the 
problem domain -- in this case parsing Java. I don't know what tech javac 
uses.)

    -- chris 

[toc] | [prev] | [next] | [standalone]

#27739

Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
>> > Does anyone else have any insight about what features of
>> > Java sources are likely culprits for stack usage peaks?
>> Can't you identify that from the source where it bails out?  Otherwise
>> anything which requires recursion to process.  That might happen during
>> parsing of deeply nested structures.
> Agreeing that the most likely culprit is some very[-very-very] deeply nested 
> syntactic construction, I'd suggest that the most likely causes are: machine 
> generated-code, and/or exuberant use of the "fluid" style -- you know the one:
>     someObject
>         .aaa()
>         .aab()
>         .aac()
>         .aad()
>     ...several pages later...
>         .zzx()
>         .zzy()
>         .zzz()
>         ;
> In the absence of further info, I bet on machine-generated code.

You landed a double hit :)  The code at hand *is* machine-generated,
and it *does* contain some rather long chains in this "fluid" style

It didn't occur to me that this would actually count as "nesting".
I thought, that after each fluid-step it would be at roughly the
same stack depth as before - not only when running that code,
but also when compiling it. Given the diagnosed high stack-use
and my utter lack of other explanations it definitely seems
plausible, and I'll examine that further.


Thanks a lot for this hint!

[toc] | [prev] | [next] | [standalone]

#27829

Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> wrote:
> Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
>> Agreeing that the most likely culprit is some very[-very-very] deeply nested 
>> syntactic construction, I'd suggest that the most likely causes are: machine 
>> generated-code, and/or exuberant use of the "fluid" style -- you know the one:
>>     someObject
>>         .aaa()
>>         .aab()
>>         .aac()
>>         .aad()
>>     ...several pages later...
>>         .zzx()
>>         .zzy()
>>         .zzz()
>>         ;
>> In the absence of further info, I bet on machine-generated code.
> You landed a double hit :)  The code at hand *is* machine-generated,
> and it *does* contain some rather long chains in this "fluid" style
>
> It didn't occur to me that this would actually count as "nesting".
> I thought, that after each fluid-step it would be at roughly the
> same stack depth as before - not only when running that code,
> but also when compiling it. Given the diagnosed high stack-use
> and my utter lack of other explanations it definitely seems
> plausible, and I'll examine that further.

I meanwhile changed the code-generator to not produce fluid-style
and that also changed a few other things for the better(*), so I'm 
quite glad of the riddance, although I haven't yet bothered to
remove the -J-Xss1m option, so still can't say yet if that really
was it about excessive javac-stack-use ;-)


(*): not directly related to the fluid-style itself, but to the
overall approach.

PS: I vaguely remember having posted something fluid-style related 
a while ago (about type-safety within the fluid), but that's not
the one I changed now. 

[toc] | [prev] | [next] | [standalone]

#27719

On 3/9/2014 10:25 AM, Andreas Leitgeb wrote:
> I recently got some Java sources that caused "javac" on
> my machine (Linux, Java 1.7, 32bit) to run out of stack
> space, while compiling fine on AIX, Java 1.7, 64bit.

What Java vendor?

AIX must be IBM Java.

But Linux could be IBM, Oracle or OpenJDK.

> I then played with option -J-Xss# and a couple of values
> for #, and found that up to about 350k it busted, while
> with 360k or more it compiled just fine. My actual problem
> is thus solved, but now I'm wondering...
>
> While 32bit platforms themselves may almost be considered
> as relicts from last millennium (ok: last decade), even
> back then I'd have expected that allowing half a megabyte
> for stack wouldn't have been considered overly wasteful.
>
> Has anyone else run into javac's default stack size limit?

No.

> Does anyone else have any insight about what features of
> Java sources are likely culprits for stack usage peaks?

It does not make any sense to me.

Arne

[toc] | [prev] | [next] | [standalone]

#27723

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 3/9/2014 10:25 AM, Andreas Leitgeb wrote:
>> I recently got some Java sources that caused "javac" on
>> my machine (Linux, Java 1.7, 32bit) to run out of stack
>> space, while compiling fine on AIX, Java 1.7, 64bit.
> What Java vendor?
> AIX must be IBM Java.
> But Linux could be IBM, Oracle or OpenJDK.

The Java on my linux machine is definitely from Oracle,
because the (dated)system's Java was 1.6, and I downloaded
and installed Java 1.7 manually from Oracle and call javac
by its full path name.

>> I then played with option -J-Xss# and a couple of values
>> for #, and found that up to about 350k it busted, while
>> with 360k or more it compiled just fine. My actual problem
>> is thus solved, but now I'm wondering...
>> Has anyone else run into javac's default stack size limit?
> No.

Does your "No" apply specifically to Oracle's 1.7 *32bit*
command-line tool "javac"? ... and *not* to eclipse, ant,
or any other suite that likely has its own separate and
likely larger default stack size?

>> Does anyone else have any insight about what features of
>> Java sources are likely culprits for stack usage peaks?
> It does not make any sense to me.

The Stack-overflows (before I added -J-Xss1m) may not make
sense, but they were a fact. Another fact is, that not all
facts necessarily make sense, though...

[toc] | [prev] | [next] | [standalone]

#27731

On 3/11/2014 10:16 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 3/9/2014 10:25 AM, Andreas Leitgeb wrote:
>>> I recently got some Java sources that caused "javac" on
>>> my machine (Linux, Java 1.7, 32bit) to run out of stack
>>> space, while compiling fine on AIX, Java 1.7, 64bit.
>> What Java vendor?
>> AIX must be IBM Java.
>> But Linux could be IBM, Oracle or OpenJDK.
>
> The Java on my linux machine is definitely from Oracle,
> because the (dated)system's Java was 1.6, and I downloaded
> and installed Java 1.7 manually from Oracle and call javac
> by its full path name.
>
>>> I then played with option -J-Xss# and a couple of values
>>> for #, and found that up to about 350k it busted, while
>>> with 360k or more it compiled just fine. My actual problem
>>> is thus solved, but now I'm wondering...
>>> Has anyone else run into javac's default stack size limit?
>> No.
>
> Does your "No" apply specifically to Oracle's 1.7 *32bit*
> command-line tool "javac"? ... and *not* to eclipse, ant,
> or any other suite that likely has its own separate and
> likely larger default stack size?

Yes. But on Windows not Linux.

>>> Does anyone else have any insight about what features of
>>> Java sources are likely culprits for stack usage peaks?
>> It does not make any sense to me.
>
> The Stack-overflows (before I added -J-Xss1m) may not make
> sense, but they were a fact. Another fact is, that not all
> facts necessarily make sense, though...

I understand that it happens.

But I find it difficult to understand how it can happen
in Java (it could easily happen in a language that allows
you to allocate arrays on the stack).

100 local variables / ints x call stack depth 100 = 40 KB

And that is already excessive for any normal code.

Arne

[toc] | [prev] | [next] | [standalone]

#27733

On 03/11/2014 11:05 PM, Arne Vajhøj wrote:

> But I find it difficult to understand how it can happen
> in Java (it could easily happen in a language that allows
> you to allocate arrays on the stack).

We're talking about the compiler here - not the JRE.  Or are you saying 
that a program in a language which allows to allocate arrays on the 
stack also requires more stack space during compilation?  I don't see 
how that would be related.

Confused.

	robert

[toc] | [prev] | [next] | [standalone]

#27735

On 3/11/2014 6:22 PM, Robert Klemme wrote:
> On 03/11/2014 11:05 PM, Arne Vajhøj wrote:
>
>> But I find it difficult to understand how it can happen
>> in Java (it could easily happen in a language that allows
>> you to allocate arrays on the stack).
>
> We're talking about the compiler here - not the JRE.  Or are you saying
> that a program in a language which allows to allocate arrays on the
> stack also requires more stack space during compilation?  I don't see
> how that would be related.

The part of the compiler that shows the problem must be written in Java
given the solution to the problem.

If that part of the compiler had been written in C/C++ then a local
variable array could eat up a lot of stack space.

The language being compiled does not matter.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web