Fully disable GC - no pauses - run with massive heap until outofmemory
Y. Srinivas Ramakrishna
Y.S.Ramakrishna at Sun.COM
Wed Feb 3 16:27:52 PST 2010
On 02/03/10 16:07, Tony Printezis wrote:
> 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.
Is there a threshold monitor that will look at generation occupancy
_before_ a GC which is what you'd want here, right? I was always
under the impression these detected occupancy after a GC and
only then would sound the alarms; but perhaps there are options
that specify precise behaviour in this regard.
Mandy, cc'd, would know for sure. (Don't know where the spec is.)
> 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:
>>> hotspot-gc-use mailing list
>>> hotspot-gc-use at openjdk.java.net
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
More information about the hotspot-gc-use