harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Date Thu, 28 Jun 2007 13:08:30 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508824

Xiao-Feng Li commented on HARMONY-4282:

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.



> [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.

View raw message