On 6/28/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Gregory Shimansky wrote:
> 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.
BTW, it is necessary that gc_cc also initialize the object header, VT
and obj_info should contain correct information after object is allocated.
Yes, this is actually the default behavior of object allocation. For
example, gc_alloc_fast API will return a well-formed object to jitted
code without any vt or obj_info manipulation by the jitted code.
Thanks,
xiaofeng
>> On 6/27/07, Gregory Shimansky (JIRA) <[EMAIL PROTECTED]> 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
--
http://xiao-feng.blogspot.com
