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] GC/VM interface discussion
Date Wed, 12 Jul 2006 04:31:25 GMT
Salikh Zakirov wrote:
> Ivan Volosyuk wrote:
>> My idea here, is if the function is required by VM, it can be emulated
>> on VM side via "alloc + pin". Of cause, it is not the same as
>> gc_pinned_alloc. The behaviour of GC will be suboptimal in that case.
> In fact, gc_alloc_pinned() is not intended to be equivalent to gc_alloc()
> followed by gc_pin() for the following reasons
> 1) gc_pin() is optional operation, and may be absent in simplest collectors
> 2) gc_pin() is not required to succeed, and the GC may decide to reject
>    object pinning (e.g. based on some memory footprint/performance compromise).
>    The success of operation must be checked by using gc_is_object_pinned()
> 3) gc_alloc_pinned() may be implemented in a much more efficient way than
>    pinning of arbitrary object, e.g. by introducing the separate fixed space
>    with size-segregated lists or other malloc-like management algorithms.
Perhaps a more relevant discussion is exactly what 
hints/suggestions/requirements the VM and MM give each other on an 
allocation request.  MMTk allows the VM to explicitly request allocation 
in a specific space, and this can/has been used to implement 
optimizations such as pre-tenuring.  IMO a good high-performance 
interface should at least allow the VM to provide a variety of hints to 
the MM.

-- Robin

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message