Ivan,
> > 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
desirable.
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]
