Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <13185596.1182846326169.JavaMail.jira@brutus>
Date: Tue, 26 Jun 2007 01:25:26 -0700 (PDT)
From: "Xiao-Feng Li (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
 between VM and GC
In-Reply-To: <23666863.1182844902607.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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