Will GC lose some locking infomation during compaction?

Y.S.Ramakrishna at Sun.COM Y.S.Ramakrishna at Sun.COM
Mon Apr 20 10:39:57 PDT 2009

Hi Colin, please look at the code for adjust_pointers() and cousins, and
related closures.
Any GC that moves objects needs to fix references to those objects
whether they are in other objects in the heap or from roots outside
the heap (in which category one would include references from thread

To learn more about how GC works, you might want to use a debugger to
step through the various GC phases and actions on a small heap to get
an idea of how this works, and then walk through the relevant code.

Good luck, and have fun!
-- ramki

On 04/20/09 09:28, Colin(Du Li) wrote:
> Hi, ramki,
> Thank you very much!
> Yes, the adjust_object works. It makes sense.
> I'm still wondering how the monitor on stack can be updated. If the object
> is moved to the new location, its monitor of the object still contains the
> object reference to the old location, right? Will it cause some problem?
> Thanks again.
> Colin
> Y. Srinivas Ramakrishna wrote:
>> Hi Colin --
>> Colin(Du Li) wrote:
>>> Hello, I still have a question.
>>> Let's say, during compaction, GC moves an object from "old Location" to
>>> "new
>>> location"(compaction top).
>>> Yes, during the marking phase we evacuated these "non-prototypical" mark
>>> words into a pair of buffers,  and used later to restore the evacuated
>>> mark
>>> words.
>>> But GC only restores mark word on object at "old Location", why don't it
>>> restore mark word on object at "new location"?
>> Not quite. You are right that at the point during the marking phase when 
>> the oops & marks are
>> saved the new location is not known, so the _preserved_oop_stack 
>> contains the old locations.
>> However, during the "adjust pointers" phase, we go over the 
>> preserved_oop_stack and
>> adjust them so they now refer to the correct "new location" that the 
>> preserved mark words
>> will go into. So when comes time to restore the mark words after the 
>> compaction/copying has
>> been completed, the preserved_oop_stack holds the right locations into 
>> which we should
>> restore the preserved mark words.
>> -- ramki
>>> Thanks a lot!
>>> Y. Srinivas Ramakrishna wrote:
>>>> init_mark() sets the mark-word into a "prototypical" state, and this 
>>>> suffices, as you surmised,
>>>> for the large majority of objects but not for all, namely for locked 
>>>> objects, biased objects and
>>>> those whose hashcodes have been computed.
>>>> Recall, however, that during the marking phase the we evacuated thse
>>>> "non-prototypical" mark words into a pair of buffers. These spooled 
>>>> mark-words
>>>> are used later to restore the evacuated mark words. Look for 
>>>> "should_preserve_mark_word()"
>>>> or similar (I do not have a workspace handy to get you the exact name).
>>>> -- ramki
>>>> Colin(Du Li) wrote:
>>>>> Hello.
>>>>> I have two questions about GC's compaction phase.
>>>>> 1. During the compaction, after GC copies a compacted object to the its
>>>>> location, it always calls "init_mark" on this object. I think
>>>>> "init_mark"
>>>>> will cause the object to be "unlocked". If the object is "locked"
>>>>> before
>>>>> compaction, will the locking information be lost after compaction?
>>>>> 2. If the compacted object has enter a monitor (using "moniterenter"),
>>>>> GC
>>>>> moves it to new location, then how can GC update the monitor?
>>>>> Thanks a lot!
>>>>> Colin

More information about the hotspot-dev mailing list