review (S) for 6958668: repeated uncommon trapping for new of klass which is being initialized

[Tom Rodriguez]

Good suggestions.  I've done both.

tom

On Jul 1, 2010, at 9:12 PM, John Rose wrote:

> Nice.  I suggest moving the big insertion in parseHelper into a private subroutine.
> 
> Also (as a more borderline thing) consider making a private subroutine for the three near-copies of the shared logic in ciIK.cpp.  (Would be parameterized by the variable part, the queried ClassState.)
> 
> -- John
> 
> On Jul 1, 2010, at 6:52 PM, Tom Rodriguez wrote:
> 
>> http://cr.openjdk.java.net/~never/6958668
>> 
>> 6958668: repeated uncommon trapping for new of klass which is being initialized
>> Reviewed-by:
>> 
>> During the execution of a class initializer only the initializing
>> thread is allowed to create instances of the class.  Currently in C2
>> this is handled by emitting an uncommon trap.  If an application
>> creates a lot of instances using this idiom it can lead to long
>> sequences of compile, uncommon trap, recompile, uncommon trap.
>> Instead C2 should emit a guarded new that allows the proper thread to
>> perform allocations throws out the code once initialization is
>> complete.  Ideally we should just be able to test that the init_thread
>> is the current thread but the init_thread is never set back to null so
>> the init_state is additionally being checked.  I'm planning to
>> separately fix the clearing the init_thread since C1 mistakenly
>> expects it to be cleared.  This fix is going to be backported to an
>> update at some point.  Tested with users application and test case
>> which I haven't bothered including though it is in the bug report.
>