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
