RFR(S): 8037842: Failing to allocate MethodCounters and MDO causes a serious performance drop

[Albert Noll]

Vitaly, Vladimir, Coleen, John, thanks for your comments.
Based on the feedback, I withdraw this RFR.

Best,
Albert

On 10/21/2014 10:25 PM, John Rose wrote:
> On Oct 21, 2014, at 12:52 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>> I suggested option 1 because if we OOM trying to allocate metaspace for MethodCounters and MethodData, then the system is pretty close to running into the metaspace limit and is not going to be able to make very much progress anyway.
> Piling on here:  OOME (or some other VM error) is a *great* way to handle resource exhaustion corner cases, but *only if* the occasion was directly (synchronously, to use David H.'s term) caused by a user event.  So in this case the JVM has to find a way to continue.
>
> In this case the JVM's internal optimization logic is stumbling, which isn't something the user can control (or usually observe).
>
>> If we run out of Metaspace while allocating metadata for a class, we throw OOM.  In the class loading case, a user can maybe catch OOM and stop loading so many classes (???).   During method compilation this is more surprising, so I'm going to change my vote for #2 now.
> I support throwing VM errors when the VM is out of resources for normal execution, but only under these conditions:
>   1. the error must be linked to a user request that somehow contributed to the resource exhaustion
>   2. the user has a reasonable chance to catch and recover from the error
>
> (Dirty secret:  That's a pretty broad permission, since the JVMS allows us to throw SOE almost anywhere; think "apush".  That's why point #2 is there.)
>
> If the conditions are not met, then the JVM has to do without the resources, with as much graceful degradation as is feasible.
>
> If the degradation is likely to felt as a bug, or if the user has turned on some sort of logging, the JVM should communicate the event appropriately, along the lines of CompileBroker::handle_full_code_cache.
>
> — John
>
> P.S.  Here's an optimization which stretches condition #1:  Sometimes the JVM can optimistically *delay* the creation of user-allocated objects, using (for example) escape analysis.  When it wins, the creation is delayed forever and the heap is never used.  In some corner cases, the delayed object must be created (at de-opt time).  At this point memory might run out.  The resulting OOME might appear to be thrown long after the user thought the object was allocated, so the causal link might be tenuous.  What this tells me is we need workable rules for deferring resource exhaustion events.