On 7/11/06, Robin Garner <[EMAIL PROTECTED]> 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.
-- 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]
