harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Date Thu, 28 Jun 2007 13:26:00 GMT
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.

> 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


Mime
View raw message