"-client" option

[Zhu Han]

On Wed, Jan 12, 2011 at 7:57 PM, Andrew Haley <aph at redhat.com> wrote:

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

That's  very helpful.  I really appreciate your response.

One more question,  please :-)

Does this behavior(MAP_NORESERVE)  consistent on other *NIX platform. For
example, OSX or freebsd?


> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110113/c0ffab3a/attachment.html