review request (S) 6866585 debug code in ciObjectFactory too slow

[John Rose]

On Aug 6, 2009, at 10:35 AM, John Coomes wrote:

> John Coomes (John.Coomes at sun.com) wrote:
>> 	http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/
>
> Anyone?

I wrote that assert code.  (I was on vacation when your review request  
went out.  And thanks for the reminder!)

The reason it's so thorough is not distrust of the local insertion- 
sort logic, but rather uncertainty about whether the GC will ever  
reorder perm-gen objects.  The point of the exhaustive re-check of  
ordering is the paranoid suspicion that the GC might have changed the  
relative order of the oops on the _ci_objects list, thereby breaking  
the binary search logic.

If that interaction between the CI and the GC were to happen, we'd  
have some badly intermittent and subtle bugs to deal with.

I suggest factoring the deleted exhaustive check into a subroutine  
which walks the whole list and verifies that it is still in order.   
For maximum paranoid defensiveness, this should be done after every  
GC.  Maybe a static variable that holds a GC tick can be used to short- 
circuit repeated checks on the same GC tick??

I don't mind putting it under a new flag, but make it diagnostic, so  
we want turn it on in the field if there are suspicious crashes.

Sorry to make you wait for this!

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090806/a8d2be6e/attachment.html