RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread (original) (raw)
Thomas Schatzl thomas.schatzl at oracle.com
Thu May 16 10:48:36 UTC 2013
- Previous message: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread
- Next message: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
On Sat, 2013-05-11 at 09:45 +1000, David Holmes wrote:
On 11/05/2013 6:53 AM, Dean Long wrote: > On 5/10/2013 1:22 PM, Peter Levart wrote: >> >> On 05/10/2013 10:08 PM, Peter Levart wrote: >>> >>> On 05/10/2013 08:10 PM, Dean Long wrote: >>>> If you really want to bullet-proof ReferenceHandler (and other >>>> system threads) against OOME caused by native allocations, >>>> then don't forget about monitor inflation if there is contention for >>>> "lock" :-)
Right - most C-heap allocation failures in the VM result in an abort but some will convert to OOME (such as native thread creation related failures). Any test that tries to force an OOME at a particular operation is going to be fragile because you can't know what other allocations might be needed under the covers. As Peter already discovered it might occur during the "new" of InterruptedException, or it might happen during the load/initialization of InterruptedException. So pre-initializing InterruptedException is probably a wise thing to do.
That means what? Should I file a new CR (against what component?) for that (making InterruptedException a pre-initialized exception)?
Thanks, Thomas
- Previous message: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread
- Next message: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]