JVMTI OOM handling when arrays / objects are too large

[Martin Buchholz]

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/~martin/jvmti-oom-test/

Thanks,

Martin

On Wed, Jun 24, 2009 at 01:15, Alan Bateman <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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090627/19fbcfd2/attachment.html