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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
