harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 30 Nov 2006 01:16:07 GMT
Mikhail Fursov wrote:
> Xiao-Feng,
> On 11/29/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>>     /* NOS (nursery object space) is higher in address than other spaces.
>>        The boundary currently is produced in GC initialization. It can
>> be a constant in future.*/
>>     public static final Address NOS_BOUNDARY = getNosBoundary();
> JIT inlines static final fields values as consts into the code for
> initialized classes today. So it's OK to initialize it on startup.
> The important issue we need to discuss is that JIT does not know the 
> details
> of implementation of any VM helper. It only knows the semantic of it's
> arguments. You wrote 2 args for the helper. Is it a general case?

Could we please have 3 arguments ?  Source object, slot and target ?  4 
would be better (srcObj, slot, tgt and mode.

And could the write barrier be substituting ?  (this is the more general 
case - if the WB is non-substituting it's impossible to implement a GC 
that requires a substituting barrier, but not vice-versa).

The two families of GC that come to mind are write-barrier based 
incremental GCs, and reference counting.

> Another issue is the date to start this work (I mean adding support for 
> this
> helper inlining to JIT). I can start this work only next week. Is it OK for
> you?

Robin Garner
Dept. of Computer Science
Australian National University

View raw message