harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Fri, 26 Jan 2007 22:54:43 GMT
Geir Magnusson Jr. wrote:
> On Jan 26, 2007, at 5:26 PM, Gregory Shimansky wrote:
>> Geir Magnusson Jr. wrote:
>>> On Jan 26, 2007, at 4:54 PM, Gregory Shimansky wrote:
>>>> Geir Magnusson Jr. wrote:
>>>>> What do you mean, "the platform doesn't have limits on stack size"?
>>>>> geir@harmony-em64t:~$ ulimit -a
>>>>> core file size          (blocks, -c) 0
>>>>> data seg size           (kbytes, -d) unlimited
>>>>> max nice                        (-e) 20
>>>>> file size               (blocks, -f) unlimited
>>>>> pending signals                 (-i) unlimited
>>>>> max locked memory       (kbytes, -l) unlimited
>>>>> max memory size         (kbytes, -m) unlimited
>>>>> open files                      (-n) 1024
>>>>> pipe size            (512 bytes, -p) 8
>>>>> POSIX message queues     (bytes, -q) unlimited
>>>>> max rt priority                 (-r) unlimited
>>>>> stack size              (kbytes, -s) 8192
>>>>> cpu time               (seconds, -t) unlimited
>>>>> max user processes              (-u) unlimited
>>>>> virtual memory          (kbytes, -v) unlimited
>>>>> file locks                      (-x) unlimited
>>>> Geir, the defaults on different systems are different. What you've 
>>>> displayed is soft limit, try "ulimit -a -H". If you see that your 
>>>> hard stack limit is unlimited, you can set your soft limit up to 
>>>> that value, that is, make it unlimited as well. And then you can 
>>>> have all the joys of unlimited stack including machine freeze 
>>>> searching for more virtual memory.
>>> What's what I was hinting at - someone is going to be surprised if 
>>> SOE doesn't work on x86_64, and the VM just falls over.
>> Ok so we agree on this topic (not the first time it seems) on that 
>> there should be a default stack limit set to the default value of the 
>> -Xss of stack limit option.
> YES! :)
>> This stack length limit discussion is getting too long. I am going to 
>> see just how hard it is to implement -Xss in DRLVM with a default to 
>> 8192Mb.
> Clearly it's really late at night for you, and you worked hard this 
> week....
> Are you really suggesting a stack size of 8 gigabytes?
> I'd suggest something like 512k, which is what the RI uses, I think.

Ah, sorry, it *is* late at night and it should have been 8192Kb which is 
the default on most linux distributions.

I remember writing a test which would create threads that just execute 
sleep in a loop, and the amount of them would be about 256 (256 * 8Mb = 
2Gb = process virtual size). Playing with ulimit -s I could make java 
process to create several thousands of threads with very small stacks. 
(The testing I've done was several years ago, it could have been that 
Sun has changed from using the system default size.)

What I want is that there *is* a default stack limit size no more than 
what system gives, and then this limit could be adjusted with -Xss 
option and other special VM execution scenarios.


View raw message