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: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Date Thu, 28 Jun 2007 14:50:13 GMT
On 6/28/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 6/28/07, Gregory Shimansky <gshimansky@apache.org> wrote:
> > Gregory Shimansky wrote:
> > > Xiao-Feng Li wrote:
> > >> Yes, exactly. The newly allocated object may have some bits set in
> > >> obj_info by GC (only possible for those bits owned by GC). The
> > >> allocation routine can guarantee the rest bits of obj_info are clear.
> > >> This situation happens, e.g., when GC sets a property flag in obj_info
> > >> so as to avoid the re-computation of the property every time using it.
> > >> One example property flag is whether the object has reference fields;
> > >> the other example is whether the object is bigger than 4KB; yet
> > >> another example is, in concurrent GC, the newly allocated object is
> > >> marked black in obj_info.
> > >>
> > >> Basically we want to set up a contract between GC and VM that, object
> > >> allocation will take care of the object header initialization.
> > >
> > > If it is guaranteed that object allocation routine also sets VT pointer
> > > correctly, then I can prepare a patch (I don't think it should be
> > > committed before we unfreeze the code) to skip the first
> > > ManagedObject::get_constant_header_size() bytes when copying memory in
> > > object_clone() and not reset any information in object header relying GC
> > > on the allocation routine.
> >
> > BTW, it is necessary that gc_cc also initialize the object header, VT
> > and obj_info should contain correct information after object is allocated.
>
> Yes, this is actually the default behavior of object allocation. For
> example, gc_alloc_fast API will return a well-formed object to jitted
> code without any vt or obj_info manipulation by the jitted code.

Btw, I think the vt and obj_info manipulation in clone() is due to the
fact that it copies the whole object from old to new, including the
object header, where the obj_info might be only valid to the old
object. If we don't copy object header, there is no need for the
obj_info reset.

> Thanks,
> xiaofeng
>
> > >> On 6/27/07, Gregory Shimansky (JIRA) <jira@apache.org> wrote:
> > >>>
> > >>>     [
> > >>> https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508516
> > >>> ]
> > >>>
> > >>> Gregory Shimansky commented on HARMONY-4282:
> > >>> --------------------------------------------
> > >>>
> > >>> There cannot be an object without VT, it can be always copied IMHO.
> > >>> But I think that object allocation already takes care about setting
> > >>> correct pointer to object's VT, so copying it in clone may be redundant.
> > >>>
> > >>> The obj_info field is reset in the GC disabled condition, so no GC
is
> > >>> possible at this moment. Do you mean that some of the last 10 bits
> > >>> may be set in the newly allocated object and VM clears them? What is
> > >>> the value of obj_info after allocation is done? Are the higher 22
> > >>> bits clear? If yes, then clearing them is not required.
> > >>>
> > >>> > [drlvm][vmcore] obj_info agreement between VM and GC
> > >>> > ----------------------------------------------------
> > >>> >
> > >>> >                 Key: HARMONY-4282
> > >>> >                 URL:
> > >>> https://issues.apache.org/jira/browse/HARMONY-4282
> > >>> >             Project: Harmony
> > >>> >          Issue Type: Bug
> > >>> >          Components: DRLVM
> > >>> >         Environment: All
> > >>> >            Reporter: Li-Gang Wang
> > >>> >            Assignee: Gregory Shimansky
> > >>> >
> > >>> > I found some issue with obj_info initialization protocol between
VM
> > >>> and GC.
> > >>> > Since there is a partitioning of the obj_info bits between VM
and
> > >>> GC (GC takes the last 10 bits), VM should not touch the last 10 bits
> > >>> without strong argument. But in following piece of code, VM assumes
> > >>> the obj_info is empty after the object is allocated. This code makes
> > >>> some GC design impossible.
> > >>> > jobject object_clone(JNIEnv *jenv, jobject jobj)
> > >>> > {
> > >>> >     ......
> > >>> >   result =
> > >>> (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length,
> > >>> vt->clss->get_allocation_handle(), vm_get_gc_thread_local());
   //
> > >>> call gc_alloc
> > >>> >     ......
> > >>> >     memcpy(result, h->object, size);   // copy the old object
> > >>> >     result->set_obj_info(0);                  // obj_info is
reset
> > >>> here
> > >>> >     ......
> > >>> > }
> > >>> > This code should be changed to remove the obj_info reset statement,
> > >>> and the memcpy should copy only the object fields part, excluding the
> > >>> object header (vt and obj_info).
> > >>>
> > >>> --
> > >>> This message is automatically generated by JIRA.
> > >>> -
> > >>> You can reply to this email to add a comment to the issue online.
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > Gregory
> >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message