harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM] GC/VM interface discussion
Date Tue, 11 Jul 2006 08:05:27 GMT

> > > GCExport Managed_Object_Handle gc_alloc_pinned();
> > > This API is currently unused.  How about we dump it for now?  (NOTE:
> > > MMTk has the concept of "immortal space".  Immortal space is never
> > > collected, never moved, only traced.  Maybe we need an immortal space
> > > kind of API instead??)
> >
> > hmm. I would prefer keeping it. The allocation mechanism is somehow
> > orthogonal to the space orginization. We used it for large object
> > allocation, which is not immortal but pinned.
> >
> > It is weird that gc_pinned_alloc is actually used. Is there some
> > misspelling in the header file?
> Pinned forever objects are lead to heap fragmentation and require
> malloc-like management. It is generally bad idea to have this kind of
> objects. But it is better then to allocate objects and pin them
> forever. Immortal space is even more dangerous, it leads to controlled
> memory leak. What kind of objects should be place in it? Thinking of
> unloading of unused classloaders - the place is definetly not for
> class objects.
> The function is not used for now and can be emulated via alloc + pin.
> No objection to strip it. It can be added again when it is needed.

malloc-like management is not an issue if used properly. alloc+pin
doesn't work unless the pinned logic is supported by alloc. In that
situation, it has no real difference from gc_pinned_alloc.

> > > GCExport void gc_write_barrier(Managed_Object_Handle p_base_of_obj_with_slot);
> > > This is a difficult API.  For starts, it only applies to write
> > > barriers written in C/asm.  Its not usable by MMTk.  "C" Write
> > > barriers that also need the ref ptr that gets written to heap will
> > > need to call a different API.  That is, unless the JIT can *inline*
> > > random chunks of C/asm and optimize across the call boundary.  A hard
> > > and ugly thing to have to do!  Since old ORP generational GC and also
> > > SableVM GC only use the above API, my vote is to leave this API "as
> > > is" for now.
> >
> > Agreed. This is too specific to be a reasonable API.
> I would like to keep this API. As we talking about C interfaces, this
> C interfaces can be used by C garbage collector. I know two places
> where the function feets perfectly: object_clone and array_copy. If  C
> garbage collector provides that function the code is simple - do the
> copying and call the function. If not, number of per-slot replacing
> write barriers should be called, which is quite slow for C garbage
> collector.
> In all other places in VM use of this function should be discouraged.

I would not suggest to define specific API for specific optimization
situations. This API usage model can be implemented in other API  by
overloading a parameter or an extra parameter if it is really


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

View raw message