Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of gshimansky@gmail.com
 designates 64.233.166.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=kDdiEviQnBXBjhT8QYgYxTfvZY5WUdXylNwgfWCMkF6/RD6+hm9Mntp7p6zENH6zVlYKL6geDQUqS//MkDz1zoMG3Qxdq8g8XSY3uHcsXtJackv7i3OFy7f/YdLmypNCNPDdOtriXFLqGcEJvNJdMPAKh3U+1hvM3f/I5e7h9y0=
Message-ID: <4683CB70.6000306@apache.org>
Date: Thu, 28 Jun 2007 18:53:36 +0400
From: Gregory Shimansky <gshimansky@apache.org>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info
 agreement
 between VM and GC
References: <23666863.1182844902607.JavaMail.jira@brutus>
	 <4915162.1182944366267.JavaMail.jira@brutus>
	 <9623c9a50706280604r3752d216i9a15b7a2ad567735@mail.gmail.com>
	 <4683B6E8.6010503@apache.org> <4683BC4D.4040001@apache.org>
 <9623c9a50706280746y57114a38q97e20ee2bd760c80@mail.gmail.com>
In-Reply-To: <9623c9a50706280746y57114a38q97e20ee2bd760c80@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregory Shimansky <gshimansky@gmail.com>

Xiao-Feng Li wrote:
> On 6/28/07, Gregory Shimansky <gshimansky@apache.org> 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