harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Date Thu, 16 Nov 2006 14:21:31 GMT
On the 0x223 day of Apache Harmony Gregory Shimansky wrote:
> Geir Magnusson Jr. wrote:
> > Gregory Shimansky wrote:
> >> Geir Magnusson Jr. wrote:
> >>> I still think that this is bogus....
> >>>
> >>> What if SOE machinery is broken?
> >>  >
> >>> We need to make this a predictable test.
> >>
> >> Well I don't feel strongly to either side. We can use ulimit -s in
> >> build.sh script which runs tests (maybe only in case it runs tests).
> > Meaning you are just as happy if it's *not* a predictable test?
> 
> Not very [1]. I just wanted to make this test to pass in a predictable
> way on "normal" distributions which do have stack limit for
> applications, and at least not to misbehave on distributions that
> don't have this default setting.
> 
> The fix is still quite questionable either way. In theory an
> optimizing JIT may inline all of the 10000000 recursions into adding
> 10000000 to the depth with no calls to function, which will produce no
> SOE.

Just make it not a tail recursion, then JIT won't inline too much. The
number is JIT-dependant in general case. But we test on conscious JITs
mostly and if such a heavy inlining eve occures, it is a good bug to
look at.

> >> I worry about two things
> >>
> >> 1. Ulimit is not a shell command, it is a bash setting. Will ulimit
> >> -s
> >> called inside of build.sh affect commands running from it, e.g. ant
> >> test? I don't want to lose SuSE server again tonight because I
> >> don't have access to its console, so it will be rebooted only in
> >> the morning :)
> > I dunno.  I'll be happy to test on a real^H^H^H^H another distro....
> >
> >>
> >> 2. What if the limit on the system is lower than 8192? Ulimit -s
> >> allows only lower than current setting in a session (otherwise any
> >> user could increase their limit to any value). So if it is set to
> >> something like 4096 the ulimit -s 8192 command will cause an error.
> > And the test will still work, right?
> 
> [1] http://article.gmane.org/gmane.comp.java.harmony.devel/18773
> http://article.gmane.org/gmane.comp.java.harmony.devel/18841
> 
> -- 
> Gregory
> 
> 

-- 
Egor Pasko


Mime
View raw message