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

[Y.S.Ramakrishna at Sun.COM]

Hi John (Rose) --

Current GCs in hotspot will never reorder perm gen objects.
Of course having the check at every full gc seems fine in debug
mode. The diagnostic mode may be paranoid given our current GC's,
but is fine to have if you feel that would still be worthwhile.

-- ramki

On 08/06/09 10:52, John Rose wrote:
> On Aug 6, 2009, at 10:35 AM, John Coomes wrote:
> 
>> John Coomes (John.Coomes at sun.com <mailto: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