harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Date Wed, 15 Nov 2006 23:54:09 GMT
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.

>> 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


View raw message