Martin,
I agree regarding the bug - this fix provides a consistent approach to
all situations where an OOME is thrown. (You can consider this an
additional review.)
My meta-question is whether OOME should have been thrown for this case:
it somehow seems wrong to me - I would not handle this
I'm far from an expert on jvmti or hotspot's error handling, but...
If I've asked for a command to be run on OOME,
having it not run feels very much like a bug.
I agree that OOME might not perfectly match the situation,
but is there a better course of action?
I don't see any reasonable alternative
Martin, Jeremy,
This change has been bugging me. I guess what I don't like is not the
"fix" but the fact that we report OutOfMemoryError for this situation in
the first place! We are not out-of-memory! We've been asked to allocate
something that is impossible to allocate given the physical con
Changeset: 74aefd0ab26d
Author:martin
Date: 2009-06-14 14:23 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74aefd0ab26d
6850720: (process) Use clone(CLONE_VM), not fork, on Linux to avoid swap
exhaustion
Summary: Use clone(CLONE_VM) on Linux; Reluctantly implement execvpe.
I've polished the changes in preparation for committing.
I'll commit once I have reviewer approval.
You'll need to let me know which forest to commit to.
Test webrev is now at:
http://cr.openjdk.java.net/~martin/jvmti-oom-test/
Now has more tests and filled-in @bug line.
Hotspot fix webrev is at
Changeset: 93c14e5562c4
Author:twisti
Date: 2009-05-06 00:27 -0700
URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/93c14e5562c4
6823354: Add intrinsics for
{Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}()
Summary: These methods can be instrinsified by using
