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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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.
