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 07:45:34 GMT
Weldon Washburn wrote:
> On 7/11/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>> 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.
>
> Yes!  I like it :)
>
>> IMO a good high-performance
>> interface should at least allow the VM to provide a variety of hints to
>> the MM.
>
> Yes!  I hope you can help us define these performance hint APIs.
>
The ones I *know* are useful are:

- Immobile (object will never move)
- Mature (for pretenuring, full-heap GC ignores)


I could speculate about a bunch of other useful hints (eg hot/cold, 
thread local, large/small ...), but probably nowhere near exhaustively - 
probably best to simply create the mechanism, define a couple of hints 
and leave it open for future use.

-- 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


Mime
View raw message