You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by gs...@apache.org on 2006/11/15 23:38:55 UTC
svn commit: r475473 -
/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Author: gshimansky
Date: Wed Nov 15 14:38:55 2006
New Revision: 475473
URL: http://svn.apache.org/viewvc?view=rev&rev=475473
Log:
Allow the test to pass even when no SOE happens in max_depth recursions
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Modified: incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java?view=diff&rev=475473&r1=475472&r2=475473
==============================================================================
--- incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java (original)
+++ incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java Wed Nov 15 14:38:55 2006
@@ -29,11 +29,10 @@
public static void main(String[] args) {
try {
func();
- System.out.println("FAIL");
} catch (StackOverflowError soe) {
System.out.println("PASS : First SOE depth = " + depth + " : " + soe);
return;
}
- System.out.println("FAIL: no SOE in " + max_depth + " iterations");
+ System.out.println("PASS: no SOE in " + max_depth + " iterations");
}
}
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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
>
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Posted by Egor Pasko <eg...@gmail.com>.
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
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Posted by Gregory Shimansky <gs...@gmail.com>.
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
http://article.gmane.org/gmane.comp.java.harmony.devel/18841
--
Gregory
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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?
>
> 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?
geir
>
>> gshimansky@apache.org wrote:
>>> Author: gshimansky
>>> Date: Wed Nov 15 14:38:55 2006
>>> New Revision: 475473
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=475473
>>> Log:
>>> Allow the test to pass even when no SOE happens in max_depth recursions
>>>
>>>
>>> Modified:
>>> incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
>>>
>>> Modified:
>>> incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
>>> URL:
>>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java?view=diff&rev=475473&r1=475472&r2=475473
>>>
>>> ==============================================================================
>>>
>>> ---
>>> incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
>>> (original)
>>> +++
>>> incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
>>> Wed Nov 15 14:38:55 2006
>>> @@ -29,11 +29,10 @@
>>> public static void main(String[] args) {
>>> try {
>>> func();
>>> - System.out.println("FAIL");
>>> } catch (StackOverflowError soe) {
>>> System.out.println("PASS : First SOE depth = " + depth +
>>> " : " + soe);
>>> return;
>>> }
>>> - System.out.println("FAIL: no SOE in " + max_depth + "
>>> iterations");
>>> + System.out.println("PASS: no SOE in " + max_depth + "
>>> iterations");
>>> }
>>> }
>>>
>>>
>>>
>>
>
>
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Posted by Gregory Shimansky <gs...@gmail.com>.
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).
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 :)
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.
> gshimansky@apache.org wrote:
>> Author: gshimansky
>> Date: Wed Nov 15 14:38:55 2006
>> New Revision: 475473
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=475473
>> Log:
>> Allow the test to pass even when no SOE happens in max_depth recursions
>>
>>
>> Modified:
>> incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
>>
>> Modified:
>> incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
>> URL:
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java?view=diff&rev=475473&r1=475472&r2=475473
>>
>> ==============================================================================
>>
>> ---
>> incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
>> (original)
>> +++
>> incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
>> Wed Nov 15 14:38:55 2006
>> @@ -29,11 +29,10 @@
>> public static void main(String[] args) {
>> try {
>> func();
>> - System.out.println("FAIL");
>> } catch (StackOverflowError soe) {
>> System.out.println("PASS : First SOE depth = " + depth +
>> " : " + soe);
>> return;
>> }
>> - System.out.println("FAIL: no SOE in " + max_depth + "
>> iterations");
>> + System.out.println("PASS: no SOE in " + max_depth + "
>> iterations");
>> }
>> }
>>
>>
>>
>
--
Gregory
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I still think that this is bogus....
What if SOE machinery is broken?
We need to make this a predictable test.
gshimansky@apache.org wrote:
> Author: gshimansky
> Date: Wed Nov 15 14:38:55 2006
> New Revision: 475473
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=475473
> Log:
> Allow the test to pass even when no SOE happens in max_depth recursions
>
>
> Modified:
> incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
>
> Modified: incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
> URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java?view=diff&rev=475473&r1=475472&r2=475473
> ==============================================================================
> --- incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java (original)
> +++ incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java Wed Nov 15 14:38:55 2006
> @@ -29,11 +29,10 @@
> public static void main(String[] args) {
> try {
> func();
> - System.out.println("FAIL");
> } catch (StackOverflowError soe) {
> System.out.println("PASS : First SOE depth = " + depth + " : " + soe);
> return;
> }
> - System.out.println("FAIL: no SOE in " + max_depth + " iterations");
> + System.out.println("PASS: no SOE in " + max_depth + " iterations");
> }
> }
>
>
>