harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM] GC/VM interface discussion
Date Wed, 12 Jul 2006 05:09:14 GMT
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


Mime
View raw message