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] Updated: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Date Tue, 26 Jun 2007 08:25:26 GMT

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

Xiao-Feng Li updated HARMONY-4282:
----------------------------------

    Description: 
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).



  was:
The original assumption on obj_info is new object has no obj_info. But I think this is not
convenient or necessarily correct to utilize obj_info sufficiently.

For example, in order to know an object is a small (<= small_threshold) or large (>large_threshold)
object, checking a bit in obj_info is more time-saving than searching its size through function
vm_object_size. This needs the according bit in obj_info to be set while allocating. But under
the original assumption, VM will reset obj_info after allocation sometimes, so that this bit
will be misleading. The following is the code resetting obj_info:

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

I suggest that we'd better modify the original assumption so that VM and GC could manipulate
bits in obj_info they are in charge of without interfering each other.

     Patch Info:   (was: [Patch Available])
     Issue Type: Bug  (was: Wish)
        Summary: [drlvm][vmcore] obj_info agreement between VM and GC  (was: [drlvm][gc] obj_info
agreement between VM and GC)

> [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: Xiao-Feng Li
>
> 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.


Mime
View raw message