Re: [Jikesrvm-researchers] Jikes object traces.

[Matthew H. <he...@cs...>]

For completeness, I felt it important to add that the trace generator in 
JMTk contains a boolean that toggles whether it computes object 
lifetimes in the "brute force" manner or if it instead should use the 
Merlin lifetime analysis algorithm.

Matthew

Matthew Hertz wrote:
> So I responded to the main message off-list, but did want to add a 
> little more information about trace generation code in JMTk.
> 
> The trace generator included with JMTk provides a complete record of all 
> object allocations and intra-heap pointer updates in order as well as an 
> out-of-order record of when each object becomes unreachable.  At 
> present, we do not include root references within the trace, but an 
> approximation of all the roots (e.g., a listing of roots at each 
> accurate point in the trace) could be generated with only a few lines of 
> code.  Because JMTk does not treat all objects in the heap as identical 
> (e.g., immortal objects are not reclaimed), the trace specifies if an 
> allocation is to the immortal region or if it is to the remainder of the 
> heap.
> 
> Anyway, this is getting to be more information then anyone wanted or 
> needed to know about tracing.  If anyone would like, please feel free to 
> ask me any questions.
> 
> Matthew Hertz
> 
> 
> Eliot Moss wrote:
> 
>>>>>>> "Balaji" == Balaji Iyengar <bri...@nc...> writes:
>>
>>
>>
>>     Balaji> I am trying to generate an object trace from the JikesRVM 
>> that
>>     Balaji> shows me the virtual address, the corresponding object and 
>> its
>>     Balaji> generation.  Any suggestions on how this could be done.
>>
>> Balaji -- Your problem statement is not clear to me. A trace is a 
>> sequence
>> of _events_. What events are you talking about? One guess I would make 
>> from
>> what you said is a trace of objects copied by a GC. What would
>> "corresponding object" mean, though? As far as a GC is concerned, the
>> virtual address _defines_ the object.
>>
>> Now Merlin, the tool developed by Matthew Hertz (whom you CC'ed on your
>> email), takes as input an object birth/copy/death trace. That trace, when
>> "normalized" as we call it, provides object births and death events, in
>> time order. (The raw trace does not have everything sorted in order, for
>> reasons having to do with how the trace is constructed -- see the Merlin
>> papers.) The raw trace identifies objects by their current virtual 
>> address
>> as well as their "object id". The object id is the number of bytes of
>> objects allocated before the object in question (i.e., the objects 
>> position
>> in a hypothetical heap that is allocated sequentially from 0 and never
>> collected). Producing a Merlin trace takes exatrtime, and inserts extra
>> data in the object header (notably the id, but also a timestamp).
>>
>> The normalized trace indicates the birth time (which is the same as the
>> object id) and the death time (the point in the trace where the object 
>> has
>> just become unreachable) of each object. (A birth record also includes 
>> the
>> allocation site (which determines the class, method, bytecode offset), 
>> and
>> object size; a death record merely gives the death time and id.)
>>
>> YOur message made it sound as if a raw trace is close to what you 
>> want. The
>> problem is that a raw trace comes from objects that are bigger than a 
>> real
>> GC would have, because of the extra bookkeeping stuff in the object
>> headers. Thus, it will not tell you what will happen in a real GC. The 
>> way
>> we do THAT is to run a normalized trace through a simulator of the 
>> real GC
>> algorithm. (This is generally faster than really GCing and all, 
>> because the
>> death records tell us which objects are dead, so we need not do a full
>> reachability analysis. However, for a generational collector, we still 
>> have
>> to do some reachability analysis, because of the dead young generation
>> objects reachable from dead old generation objects that we have not yet
>> collected. Thus, a simulator needs to know about the pointers in 
>> objects as
>> well. So ... our traces also include adequate pointer update records for
>> that.)
>>
>> If you're interested in exploiting this technology, I suggest you 
>> pursue it
>> with Matthew off the list.
>>
>> Regards -- Eliot
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> Jik...@os...
>> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-researchers 
>>
> 
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jik...@os...
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-researchers 
>