Request for review 6988439: Parallel Class Loading test deadlock involving MethodData_lock and Pend, ing List Lock

[Tom Rodriguez]

On Dec 9, 2010, at 4:30 PM, Y. Srinivas Ramakrishna wrote:

> That would be (some of) the methods executed by the reference handler thread
> only. I suggested a refworkload run, but i suspect the difference will
> be a wash (famous last words?).

I think the way it works out is that we will delay profiling of ReferenceHandler.run slightly.  We create MDO on entry and on backedges.  There are two backedges in run, one where the lock is held and one where it isn't, so we should eventually create it.

tom

> 
> -- ramki
> 
> On 12/9/2010 4:07 PM, David Holmes wrote:
>> Hi Coleen,
>> 
>> This will certainly avoid the deadlock, but what affect does it have on the functionality if we just
>> ignore this request to profile a method?
>> 
>> Thanks,
>> David
>> 
>> Coleen Phillimore said the following on 12/10/10 02:35:
>>> Summary: Don't acquire methodData_lock while holding pending list lock
>>> 
>>> We discussed the alternative of allocating the methodData object from permgen before acquiring the
>>> MethodData_lock, but were concerned about leaking methodData objects in the permgen if another
>>> thread beats us to the locked region. When we go to native memory for these objects this bug fix
>>> will be moot and removed. This patch is to prevent the various hangs we've seen from occurring
>>> until then.
>>> 
>>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/
>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246
>>> 
>>> Thanks,
>>> Coleen
>