harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elena Semukhina" <elena.semukh...@gmail.com>
Subject Re: [drlvm][stacks] How large is stack size limit?
Date Mon, 11 Dec 2006 13:44:56 GMT
Pavel,

what is incorrect in the test?

It passes on windows on IBM VME and JRockit. As for the magic number 7000, I
think the author of the test considered it quite satisfactory . In the
comments to the test he wrote that an alternative java craches with
200000:).

The JVM Spec reads:
 * If the computation in a thread requires a larger Java virtual machine
stack than is permitted, the Java virtual machine throws a
StackOverflowError.

So throwing StackOverflowError is legal and the stack size limit depends on
implementation. The question is whether the test has to pass on the current
DRLVM implementation. If it fails legally, then we should fix the test so
that it reflects the status quo.

Thanks,
Elena

On 12/11/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
> I think that test is invalid. It doesn't pass on windows RI , so … no
> comments. Also it is not clear why depth should be 7000. I can find this
> magic value in any spec.
>
> Pavel Afremov.
>
>
>
> On 12/11/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> >
> > Hello all,
> >
> > The smoke test stress.Stack fails with StackOverflowError on Windows and
> > linux/INT. It passes only on linux/JIT now.
> > The test algorithm is simple: a method calls itself recursively for 7000
> > times. The test fails if StackOverflowError is thrown.
> >
> > The following are the numbers of iterations before the test fails:
> >
> > Windows:
> > INT: 353
> > JET: 3963
> > OPT: 32264
> > RI*: 3689
> >
> > Linux:
> > INT: 587
> > JET: 7762
> > OPT: 72105 (!!!)
> > RI*: 61837
> >
> > *RI is Java(TM) 2 Runtime Environment, Standard Edition (build
> > 1.5.0_08-b03
> > ).
> >
> > Are these numbers expected? Are there any restrictions on stack size in
> > DRLVM?
> >
> > --
> > Thanks,
> > Elena
> >
> >
>
>


-- 
Thanks,
Elena

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message