On 03/05/09 04:18, David Holmes - Sun Microsystems wrote:
Hi Mandy,
Isn't this kind of change risky? With static initialization you know
that once the VM gets up and running then everything is in place. But
with lazy-initialization (and using reflection no less!) there's a
danger that when you try to initialize you're more likely to fail due to
lack of memory or resources.
That's a good point. I change the getSystemShutdownHooks() method to
return a preallocated array. The initialization of the hooks themselves
are not changed by this fix. However, if the application shutdown
hook adds the first file to be deleted on exit, the lazy initialization
may cause some trouble. I'll look into it and send out a new webrev.
I ran the jtreg tests and I am going to run the JCK tests to make sure
no regression.
I can't quite tell exactly when these
setSharedSecret methods will be called.
When SharedSecrets.getJava*Access() method is called, it will
SharedSecrets.setSharedSecret() which in turn calls
<cls>.setSharedSecret() method of the given cls.
BTW I think the comments copied into
src/share/classes/java/io/DeleteOnExitHook.java need to be reviewed -
they made sense when the code was java.io.File, but not now :)
Ok.
Thanks
Mandy
Cheers,
David
Mandy Chung said the following on 03/05/09 17:01:
6810254: Lazily instantiate the shared secret access objects
Webrev at:
http://cr.openjdk.java.net/~mchung/6810254/webrev.00/
sun.misc.Java*Access objects are created at initialization time.
However, they are not always needed. They can be instantiated lazily
when needed. The fix is to add a static setSharedSecret() method to
be called by sun.misc.SharedSecrets via reflection when the shared
secret access object is requested.
Thanks
Mandy
