SOE for x86_64 isn't required very mach, because this platform
hasn't
limits
on stack size. The other case when this limits is set specially
by ulimit
–s
command. For this configuration test should broke VM and should be
excluded.
But for x86_64 ONLY!
On x86_32 it should works. Degradation on RHEL4 founded by
Weldon should
be
investigated.
BR
Pavel Afremov.
On 1/25/07, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>
> On 1/25/07, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> >
> > SOE implementeation for x86_64 platform was not contributed
due a bug
in
> > threading system. SOE for x86_32 should works on any platform.
> >
> > Weldon When did you notice that on your x86_32 machine? Did
it works
> > before
> > or you didn't run tests on your RHEL4 machine before?
> >
> >
> >
> > I think that StackTest should be excluded. We should find
changes
which
> is
> > source of the crash.
>
>
> Pavel,
>
> StackTest, stress.Stack and exception.FinalizeStackTest are
excluded for
> Linux x86_64 and *http://issues.apache.org/jira/browse/
HARMONY-2972* has
> been filed to track this issue. Could you please add a comment
to this
> issue?
>
> Besides, the overall picture of excluded smoke tests could be
seen in
the
> http://wiki.apache.org/harmony/DRLVMInternalTests page
>
> Elena
>
>
> > Thanks.
> >
> > Pavel Afremov.
> >
> >
> >
> >
> > On 1/15/07, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> > >
> > > On 1/14/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > >
> > > > Geir Magnusson Jr. wrote:
> > > > >
> > > > > On Jan 12, 2007, at 7:53 AM, Gregory Shimansky wrote:
> > > > >
> > > > >> Elena Semukhina wrote:
> > > > >>> I tried StackTest in jitrino debug mode on both
SUSE9 linux 2
> CPU
> > > > >>> ia32 and
> > > > >>> em64t machines. It passed. It is now excluded for
linux x86_64
> > > > (probably
> > > > >>> Geir has excluded it because it always passed for me).
> > > > >>> I ran it on that platform and saw rather strange
behavior. The
> > test
> > > is
> > > > >>> essentially the same as stress.Stack: both tests
invoke a
method
> > > > >>> recursively
> > > > >>> waiting for StackOverflowError. The difference is
that the
> method
> > is
> > > > >>> void in
> > > > >>> StackTest and boolean in stress.Stack. Another
difference is
> that
> > > > >>> StackTest
> > > > >>> should never fail: it detects both throwing
StackOverflowError
> and
> > > not
> > > > >>> throwing it as normal situation. Doing that it
passes even
with
> > > > >>> 200000000
> > > > >>> iterations with no StackOverflowError (!) (JIT)
while on RI it
> > gets
> > > > >>> StackOverflowError after 650000 iterations. On drlvm
linux
ia32
> it
> > > > gets
> > > > >>> exception after 8600 iterations. It also gets the
exception in
> > > > >>> interpreter
> > > > >>> mode on em64t (about 2400 iterations).
> > > > >>> Can this be correct behavior?
> > > > >>
> > > > >> If you use SuSE9 on x86_64, then most likely it is
because of
> > > > >> weirdness of SuSE9 installation. It has no hard or
soft stack
> limit
> > > by
> > > > >> default (see ulimit -s). You can try to limit stack
size like
> > ulimit
> > > > >> -s 8192 and then this test should not give too many
iterations.
> If
> > > you
> > > > >> upgrade to SuSE10, you will see that it has default
stack limit
> > 8192.
> > > > >>
> > > > >> The current implementation of SOE in drlvm is that it
takes
stack
> > > size
> > > > >> from the system. If system has no limit, then stack
has no
limit
> as
> > > > >> well. It has been discussed in other threads about
SOE that
this
> is
> > > > >> not very good, but hasn't been fixed AFAIK.
> > > > >>
> > > > >
> > > > > I think that if we can find a way to have an "cononical
> environment"
> > > for
> > > > > linux that get set before running the tests, that
would be
useful.
> > > >
> > > > I agree. I think the easiest way would be to implement -
Xss option
> for
> > > > drlvm and use it for those tests which actually depend
on stack
size
> > > > like StackTest and stress.Stack.
> > >
> > >
> > > This task is already declared at
> > > http://wiki.apache.org/harmony/CoreVmDevelopmentItems page.
> > > I think there should be also a default stack size value
for the
> systems
> > > with
> > > unlimited stack size. The test shows that RI definitely
limits stack
> > size
> > > on such systems.
> > >
> > > BTW, should we also change the test so that it fails after
creating
a
> > huge
> > > number of stack frames?
> > >
> > > Elena
> > >
> > >
> > >
> > > > --
> > > > Gregory
> > > >
> > > >
> > >
> > >
> > > --
> > > Thanks,
> > > Elena
> > >
> > >
> >
> >
>
>
> --
> Thanks,
> Elena
>
>
