Fully disable GC - no pauses - run with massive heap untiloutofmemory

[anthony.warden at nomura.com]

Many thanks Tony and Ramki. That's exactly what I need and Tony also guessed the next step :)



---------------------------------

----- Original Message -----
From: Antonios.Printezis at sun.com <Antonios.Printezis at sun.com>
To: ysr at sun.com <ysr at sun.com>
Cc: Warden, Anthony (IT/UK); hotspot-gc-use at openjdk.java.net <hotspot-gc-use at openjdk.java.net>
Sent: Thu Feb 04 00:07:11 2010
Subject: Re: Fully disable GC - no pauses - run with massive heap untiloutofmemory

Hi Anthony,

I hope you are well!

An alternative is to use an MBean and monitor the occupancy of the eden. 
When that goes over a certain threshold, you can somehow kill the JVM. 
In fact, you can be a bit more graceful this way, since you can notice 
early-ish that the JVM will run out of memory a bit into the future and 
shutdown all processing gracefully (i.e., let the current Tx complete), 
while redirecting new requests to a new JVM.

Are you going to have any long-lived data in the JVM? Maybe, size the 
old generation large enough to accommodate it and after initialization 
do a System.gc() to move all that into the old generation. That way, 
you'll start processing with a totally empty eden.

GC group: should we really be encouraging this? :-)

Tony, HS GC Group

Y. Srinivas Ramakrishna wrote:
> Hello Anthony --
>
> On 02/03/10 14:43, anthony.warden at nomura.com wrote:
>   
>> How best to do this please?
>>
>> Command line options / hack the gc thread etc.
>>     
>
> Shape the heap so as to give all (or most) of it to the young gen,
> use no survivor spaces. For example, say you want a 32 G heap.
> Let's give 4 M to the old gen may be. So you could do:-
>
>    -Xmn32g -Xmx(32*1024+4)m -Xms(32*1204+4)m -XX:SurvivorRatio=1g
>
> (of course you use the computed values of the expressions in parentheses above.)
>
> Unfortunately, this will not give you an OOM when the heap gets
> full. It'll trigger a scavenge. If you want to give up the ghost at
> the first scavenge you can (if you are running on Solaris for example)
> write a Dtrace script to detect the invocation of a GC and kill
> the JVM process. Don't know if that's the behaviour you seek here.
>
> -- ramki
>
>   
>>
>> ---------------------------------
>>
>>
>>
>> This e-mail (including any attachments) is confidential, may contain
>> proprietary or privileged information and is intended for the named
>> recipient(s) only. Unintended recipients are prohibited from taking action
>> on the basis of information in this e-mail and must delete all copies.
>> Nomura will not accept responsibility or liability for the accuracy or
>> completeness of, or the presence of any virus or disabling code in, this
>> e-mail. If verification is sought please request a hard copy. Any reference
>> to the terms of executed transactions should be treated as preliminary only
>> and subject to formal written confirmation by Nomura. Nomura reserves the
>> right to monitor e-mail communications through its networks (in accordance
>> with applicable laws). No confidentiality or privilege is waived or lost by
>> Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
>> a reference to any entity in the Nomura Holdings, Inc. group. Please read
>> our Electronic Communications Legal Notice which forms part of this e-mail:
>> http://www.Nomura.com/email_disclaimer.htm
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>     
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>   



This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20100204/271f8793/attachment-0001.html