harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Date Thu, 28 Jun 2007 14:14:26 GMT

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

Gregory Shimansky updated HARMONY-4282:
---------------------------------------

    Attachment: HARMONY-4282.patch

Attached patch fixes Object.clone not to copy VT and obj_info files from the source object.
GC should make sure that they are initialized correctly at object's allocation time. This
includes both gcv5 and gc41 for drlvm.

I've ran classlib's security tests which allegedly utilize Object.clone function and all tests
passed. I wonder about other workloads which could use Object.clone to test that it works
correctly.

Patch shouldn't be committed before M2 milestone passes.

> [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
>         Attachments: HARMONY-4282.patch
>
>
> 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