On 7/11/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 7/12/06, Geir Magnusson Jr <geir@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
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
|