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.
I think that we learned that depending on the default is dangerous.
Try "ulimit -s unlimited" :)
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.
So maybe we should ensure that we can do something that can't be
optimized away...
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
