Xiao-Feng Li wrote:
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.
I've created a patch in HARMONY-4282. It can be committed when we
unfreeze the code.
I would also like to know where Object.clone function is used a lot, so
that I could test the patch. Does anyone know?
--
Gregory
