"-client" option

[Andrew Haley]

On 01/12/2011 10:08 AM, Zhu Han wrote:
> On Tue, Jan 11, 2011 at 6:57 PM, Andrew Haley<aph at redhat.com>  wrote:
>
>>   640MB is just the pre-allocated address space size, half of them are
>>> anonymous mmap region.  RSS is just around 48MB.  I want to control the
>>> total size of  address space because the JVM process spawns several
>>> sub-process to execute some scripts provided by OS occasionally. I know
>>> this
>>> is not portable, but seems like there is no better way to open a URL in
>>> standalone browser from a java application.
>>>
>>
>> But these regions are mapped as MAP_NORESERVE, so it shouldn't matter.
>>
>>
>>   This may be failed because of lack of swap space to backup address space.
>>>
>>
>> OK, so now I understand what the real problem is.
>>
>> I'm assuming Linux.
>>
>> I don't understand why this is happening.  I wonder if you have some
>> odd setting.
>>
>> What is /proc/sys/vm/overcommit_memory?  /proc/sys/vm/overcommit_ratio?
>>
>> /proc/meminfo ?
>>
>
> Because it will be deployed as a desktop application. So I have no control
> over settings of /proc/sys/vm/overcommit_memory. And some distributions set
> it as 0, at least it is 0 on my Ubuntu 10.04.

0 should be fine.

> The failure can be observed only on resource limited environment.
>
> I have written a small script and communicate with JVM through local
> loopback TCP connection. This is a possible workaround. But, it is quite
> ugly...

I've had a look, and the big mappings seem to be
MAP_PRIVATE|MAP_NORESERVE per-thread regions allocated for the malloc
heap by glibc.  Every thread has its own heap, and these are
pre-allocated in 64M chunks.  A bunch of special-purpose threads are
started by the VM, so you have a multiple of these 64M mappings.  So,
I don't think there's much you can do about it.

But in any case, MAP_NORESERVE doesn't reserve memory, so you
shouldn't start getting an OOM condition until you really run out of
memory, not just address space.

Andrew.