[opinion] javac's default stack space

[Andreas Leitgeb]

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?

 

[Robert Klemme]

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

 

[Andreas Leitgeb]

Never.

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

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.

 

[Arne Vajhøj]

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

 

[Andreas Leitgeb]

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.

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?

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

 

[Arne Vajhøj]

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.


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.

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

 

[Robert Klemme]

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.

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

 

[Robert Klemme]

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

 

[Arne Vajhøj]

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

 

[Andreas Leitgeb]

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!

 

[Andreas Leitgeb]

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.