harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm][stacks] How large is stack size limit?
Date Mon, 11 Dec 2006 15:42:39 GMT
FYI

Stack size doesn't depend on -Xss  setting now. DRLVM doesn't support it.

Also DRLVM doesn't crash on the test, it throws SOE.



Pavel.

On 11 Dec 2006 21:34:31 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> On the 0x23C day of Apache Harmony Elena Semukhina wrote:
> > On 12/11/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> > >
> > > Elena,
> > >
> > >
> > >
> > > You wrote:
> > >
> > >   RI*: 3689
> > >
> > >
> > >
> > > It's mean that test is failed on RI, isn't it?
> > >
> > > So 7000 isn't correct for RI. Let's change it to 3000. And test
> start's
> > > pass
> > > on our VM.
> >
> >
> > It will fail in the interpreter mode :(.
> >
> > Since this functionality depends on implementation, the test may pass
> here
> > and fail there.
> > I'd like to hear from DRLVM gurus that e.g. the test is incorrect
> because
> > the stack size limit in the DRLVM is restricted to some value which
> cause
> > StackOverflowError and the correct number in the test should be XXX. I
> know
> > that 200 is acceptable :) but should it be larger?
>
> stack size limit in DRLVM depends on:
> * mode (opt/jet/int)
> * -Xss (default) setting
> * the test itself and current set of optimizations like inlining
> heuristics which are subject to constant change
>
> the question is: do we want a test that would fail often due to
> various (valid) configuration changes in DRLVM? I think, no. Though,
> it makes sense to create a stress test with intensive stack usage, on
> which we should not crash.
>
> > Elena
> >
> > Pavel.
> >
> >
> > On 12/11/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> > >
> > > 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
> > >
> > >
> >
> >
> >
> >
> >
> > --
> > Thanks,
> > Elena
>
> --
> Egor Pasko
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message