On 7/11/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 7/12/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> >
> > 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()
>
> Do you mean gc_pin_object()? It returns void. Why not have it return
> an indication of success? I mean, it knows, right?
>
My understanding is, as a hint to GC, gc_pin_object() leaves GC to
decide when and how to react; so the immediate return value may not be
very informative to indicate the status of an object pinning, since GC
may pin it later in next collection, the API itself doesn't need to
know the result. The gc_is_object_pinned is used to check the pinning
status.
That said, it's still ok to return the current pinning status at the
return time.
Some clarification. 1) A grep of drlvm turns up no such thing as
"gc_pin()". 2) its not clear that an interface where the GC may or
may not pin an object is useful. If C code requires an object to be
pinned, what would it do? Wait an arbitrary amount of time then call
gc_is_object_pinned repeatedly in hopes the GC will finally say "yes"?
This could lead to deadlock problems 3) Note GCV4's gc_pin_object()
implementation always pins the object. 4) There is nothing in gc.h
comments to indicate gc_pin_object() may or may not actually pin the
object in question.
Pinning an object is a tricky API. There is definitely a need to pin
objects temporarily. In the best case, a GC algorithm will react by
pinning just the amount of memory an object occupies. In the worst
case, pinning an object will cause a region of memory surrounding the
object to be skipped during GC cycle -- which in turn might cause GC
latency/footprint/thruput problems. Regions could be 8KB, 512KB or
even megabytes.
Pinning objects for arbitrary lengths of time is not really a good
idea. Also, if it is known at creation time that an object must never
move, the preferred API is gc_alloc_pinned(). I don't know of any
legitimate environments that need more than pinning objects
temporarily coupled with allocating pinned objects. Anyone have any
thoughts/data on this?
Thanks,
xiaofeng
---------------------------------------------------------------------
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]
