Hi Mandy,
This all seems quite reasonable to me.
Two minor nits:
1. The "delay ntil" typo in Finalizer.java is still present.
2. In VM.java. booted need not be volatile now that it is only accessed
within a locked region. Also awaitBooted might as well be void as it can
only ever return true.
Thanks,
David
On 5/11/2013 6:04 AM, Mandy Chung wrote:
Thank you all for the suggestions.
Before the VM initialization is completed, any agent ought to be careful
in what things it can do and what shouldn't do. I think it's reasonable
to ignore System.runFinalization if it's called at early startup phase.
I'm unclear if there is any use case that we really require finalization
to happen before VM is booted (I can imagine other problems may happen).
I change the runFinalization and runAllFinalizers methods to return if
it's not booted and also change runFinalizer method to take
JavaLangAccess to simplify the synchronization instead of caching it in
the static field.
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.02/
David - I decided to leave VM.awaitBooted as it is. Having the callsite
to call awaitBooted makes it explicit and clear that it's blocking and
we will keep SharedSecrets.getJavaLangAccess method consistent with the
other SharedSecrets methods that they are all getter methods. If any
future change calls SharedSecrets.getJavaLangAccess before it's booted,
it's a little easier to diagnose (NPE vs hangs).
Peter - thanks for the ObjectAccess idea. I don't think supporting
finalization to happen before VM is booted buys us anything and I would
rather keep this change simple.
Mandy
