On 7/11/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> On 7/11/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
>> > > > > GCExport void gc_write_barrier(Managed_Object_Handle
>> p_base_of_obj_with_slot);
>> > > > > This is a difficult API. For starts, it only applies to write
>> > > > > barriers written in C/asm. Its not usable by MMTk. "C" Write
>> > > > > barriers that also need the ref ptr that gets written to heap
>> will
>> > > > > need to call a different API. That is, unless the JIT can
>> *inline*
>> > > > > random chunks of C/asm and optimize across the call
>> boundary. A hard
>> > > > > and ugly thing to have to do! Since old ORP generational GC
>> and also
>> > > > > SableVM GC only use the above API, my vote is to leave this
>> API "as
>> > > > > is" for now.
>> > > >
>> > > > Agreed. This is too specific to be a reasonable API.
>> > >
>> > > I would like to keep this API. As we talking about C interfaces,
>> this
>> > > C interfaces can be used by C garbage collector. I know two places
>> > > where the function feets perfectly: object_clone and array_copy.
>> If C
>> > > garbage collector provides that function the code is simple - do the
>> > > copying and call the function. If not, number of per-slot replacing
>> > > write barriers should be called, which is quite slow for C garbage
>> > > collector.
>> > > In all other places in VM use of this function should be
>> discouraged.
>> >
>> > I would not suggest to define specific API for specific optimization
>> > situations. This API usage model can be implemented in other API by
>> > overloading a parameter or an extra parameter if it is really
>> > desirable.
>>
>> The is not suitable from performance point of view. Extra parameter if
>> checked each time will degrade performance substantially. Write
>> barrier is performance critical peace of code and should be very
>> simple and optimal. This API can also be declared as _optional_. If
>> the
>> GC doesn't export this optimized function, VM can fallback to general
>> case when all slots
>> of the object should be updated by separate write barrier calls.
>>
>
> My experience was that write barrier performance is decided by the
> condition checking(s) in fast path. Have you any data showing this API
> is important for certain benchmarks?
>
> Thanks,
> xiaofeng
>
There are two papers I can think of off the top of my head that are
relevant to this question.
_Blackburn, S. M._ and Hosking, A. L. *Barriers: Friend or Foe?* /
The 2004 International Symposium on Memory Management (ISMM 2004)
<http://www.research.ibm.com/ismm04/>
/_Blackburn, S. M._ and McKinley, K. S. *In or Out? Putting Write
Barriers in Their Place* /
The 2002 International Symposium on Memory Management (ISMM 2002)
<http://www.hpl.hp.com/personal/Hans_Boehm/ismm>
/
Both available from
http://cs.anu.edu.au/~Steve.Blackburn/pubs/abstracts.html
For best performance, the fast path of both the allocation sequence and
the write barrier should be inlined into the mutator, and especially for
the write barrier the slow-path needs to be out-of-line (see "In or Out"
paper for details). I gather the usual approach is to provide
hand-crafted IR for each operation, so perhaps there should be an
additional API function along the lines of
void *get_IR(<various parameters to define operation>)
get_IR() is a messy approach but short of rewritting everything in
Java, I don't see a better alternative.
where the compiler can request a chunk of IR to optimize certain
operations - and if the MM can't provide it, simply compile a function call.
Also for completeness, read barriers should be considered. While MMTk
CVS head doesn't currently use this, various people have patches that
implement them, and we are keen to add this to MMTk real soon now.
Lastly, and this may or may not be appropriate to consider in the
context of DRLVM, consideration should be given to barriers on statics
and non-pointer fields. The various transactional approaches to
synchronization make use of these, and IMO this is going to be a big
area in the not too distant future. OTOH, this is probably such a
pervasive change that it would be best to engineer a new VM with these
kinds of barriers in place from the start.
I agree with the above. The problem at hand is to deliver a JVM that
works today while allowing a migration path to a transactional
tomorrow.
-- Robin
/
/
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
