JVMTI OOM handling when arrays / objects are too large

[David Holmes - Sun Microsystems]

Hi Martin,

Martin Buchholz said the following on 06/30/09 07:58:
> Could someone change the synopses of bugs as follows:
> 
> 6850958: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit
> 6850957: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit
> 
> I've changed URLS to be as follows
> http://cr.openjdk.java.net/~martin/OnOutOfMemoryError/
> http://cr.openjdk.java.net/~martin/OnOutOfMemoryError-test/

The CRs have been updated and the Hotspot CR moved to runtime from 
JVMTI. I've referenced this email thread, linked to webrevs and 
cross-linked CRs.

>     One issue with the test however: there were four changes made to the
>     VM code, but there are only three test cases! Which one is missing?
> 
> Hmmmm.... instanceKlass may not be exposed to Java code -
> only for arrays of VM-internal objects.
> Can a real hotspot engineer confirm?

Hmmm instanceKlass seems to be the main one used AFAICS:

JRT_ENTRY(void, Runtime1::new_object_array(JavaThread* thread, 
klassOopDesc* array_klass, jint length))

calls

oopFactory::new_objArray(elem_klass, length, CHECK);

calls

  ((instanceKlass*)klass->klass_part())->allocate_objArray(1, length, 
THREAD);

which appears to tbe instanceKlass allocate_objArray.

But I'd rely more on a printf inside the methods that a visual code walk :)

David

> Thanks,
> 
> Martin
> 
> 
> 
> 
>  
> 
> 
>     And as Alan suggested, as I'm not an official runtime member these
>     days, someone from runtime should also "rubber stamp" this.
> 
>     Thanks,
>     David
> 
>     Martin Buchholz said the following on 06/28/09 09:58:
> 
>         Alright, I have a new simple version of the hotspot part of the
>         jvmti-oom fix that should make Alan happy.
> 
>         ...Except for the usual problem that the code is screaming
>         for a bit of refactoring, and it's not quite clear what file
>         and function name it should be refactored to.  I'll do the
>         easy refactoring if you give me the names to use.
>         Or simply give me thumbs up and I will commit.
> 
>         http://cr.openjdk.java.net/~martin/jvmti-oom/
>         <http://cr.openjdk.java.net/%7Emartin/jvmti-oom/>
>         http://cr.openjdk.java.net/~martin/jvmti-oom-test/
>         <http://cr.openjdk.java.net/%7Emartin/jvmti-oom-test/>
> 
>         Thanks,
> 
>         Martin
> 
>         On Wed, Jun 24, 2009 at 01:15, Alan Bateman
>         <Alan.Bateman at sun.com <mailto:Alan.Bateman at sun.com>
>         <mailto:Alan.Bateman at sun.com <mailto:Alan.Bateman at sun.com>>> wrote:
> 
>            David Holmes - Sun Microsystems wrote:
> 
>                Jeremy,
> 
>                As I see it there was no consensus reached on whether this
>                change should be made. I have some reservations as previously
>                outlined, but Alan seemed to be of the view that the current
>                situation was deliberately chosen - which implied to me (Alan
>                correct me if I'm wrong) that he opposed the change.
> 
>                It may be that including this case in the OOM onError
>         handling
>                is okay, but that the JVMTI event posting is not. But
>         Alan will
>                need to clarify his position on that.
> 
>            You got it. My view is that we should not post a JVM TI
>            ResourceExhausted event for this case.
> 
>            I think Jeremy's original motive was to have the
>         OnOutOfMemoryError
>            actions run. I don't see a problem changing the code to do that.
>            Yes, the current behavior is deliberate but this option is for
>            troubleshooting and maybe it can help with the (probably
>         rare) cases
>            where this happens.
> 
>            The other point I attempted to make is that if both
>            OnOutOfMemoryError and HeapDumpOnOutOfMemoryError are enabled
>         then
>            we should always generate the heap dump before the
>            OnOutOfMemoryError run. I think we are in agreement that the heap
>            dump is not interesting here but we should still generate it
>         anyway.
> 
>            -Alan.
> 
> 
>