RFR(XXS): 8001028: Improve GC option handling

[David Holmes]

Thanks John, I've officially Reviewed it.

As I've said internally I won't be surprised if there is some 
obscure/unusual use of flags or agents or some other debugging thing 
that is affected by this. But it seems unlikely and it is much nicer to 
have the VM fail cleanly than crash bizarrely. For the reader another 
way this easily manifest this is if you have a low "maximum number of 
user processes" limit on linux and are near that limit when you try to 
launch the VM.

David

On 5/12/2012 8:55 AM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple volunteers review the changes for this CR? The
> webrev can be found at: http://cr.openjdk.java.net/~johnc/8001028/webrev.0/
>
> Summary:
> When the JVM is starting up on a system that is out of native resources
> (perhaps as the result of the user specifying too large a number of GC
> threads), the creation of the Finalizer thread can fail. When this
> happens the JVM attempts to throw an out of memory error which can lead
> to assertion failures and crashes because the class for java.lang.Class
> has not yet been initialized. Changing the initialization order so that
> the initialization of java.lang.Class comes before
> java.lang.ref.Finalizer allows the JVM to exit in a more orderly fashion.
>
> Testing:
> Command line testing with some code inserted into the thread creation
> code to force ENOMEM returns; jprt; nsk gc, jit, regression tests.
>
> This change has already been reviewed internally so I'm interested in
> hearing from folks who might be affected by the change in initialization
> order.
>
> Thanks,
>
> JohnC
>