Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of trojanyuan@gmail.com designates
 209.85.198.238 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=BypNj3P1IcUUjZLsKzuQidIl72u/aKxyEX8ikzSeWLox8zKkR4s6xv70Z94gdxxgu+
         0BRc1zRnimIcwWX7oDjt9RTgZ+pT4J8zfuyrgTp3Xd645s6I6P3hicUWLUMbFQ0rVA+K
         Abe+bH2uTedoieHAH+LbWOLOFX90wvGPQluhc=
MIME-Version: 1.0
In-Reply-To: <e0f125db0902190847v78c0f3f7m681475332f0951af@mail.gmail.com>
References: <a2d9c7400902190409y1bf843adn211188b7d44d6db5@mail.gmail.com>
	 <c30d70960902190423i45caa652leb32be1e85829d4b@mail.gmail.com>
	 <a2d9c7400902190457v6fce5beah35fffaa81c1f6448@mail.gmail.com>
	 <e0f125db0902190847v78c0f3f7m681475332f0951af@mail.gmail.com>
Date: Fri, 20 Feb 2009 09:21:53 +0800
Message-ID: <a2d9c7400902191721p54d2d2ffyb67385581c438ada@mail.gmail.com>
Subject: Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
	in GarabageCollector?
From: Yuan Zhang <trojanyuan@gmail.com>
To: dev@harmony.apache.org
Content-Type: multipart/alternative; boundary=000e0cd14cb45fedf704634f7a21

--000e0cd14cb45fedf704634f7a21
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

I have noticed that the least 10 significant bit of obj_info field in struc=
t
ManagedObject is used to store hashcode of a ManagedObject, but it seems
that gc use the least 8 significant bit to store some gc-concerned
information such as mark-bit, I wonder if this may cause problems? Because =
I
have little knowledge of the usage of hashcode in the ManagedObject.

2009/2/20 Pavel Pervov <pmcfirst@gmail.com>

> This is the data interface between the VM and a GC. GC must know some
> details of object layout in the heap to be able to implement
> collection algorithms efficiently.
>
> Pavel.
>
> On Thu, Feb 19, 2009 at 3:57 PM, Yuan Zhang <trojanyuan@gmail.com> wrote:
> > Alexei,
> > Thanks for your answer. Can I understand this problem in this way:
> >     -----at the current edition of harmony, an Partial_Reveal_Object
> > pointer is just casted from a ManagedObject pointer, and the purpose of
> the
> > duplicate declaration of the struct is to minimize dependency between g=
c
> and
> > vmcore because in the future the two structs may have different
> > declarations.
> >
> > 2009/2/19 Alexei Fedotov <alexei.fedotov@gmail.com>
> >
> >> Yuan,
> >> The intention of this construct is to minimize dependency between gc
> >> and vmcore limiting interfaces to C-type ones. If you changed layout
> >> of fields, you should update GC struct. If you only changed vt
> >> functions, then probably the problem is in other place.
> >>
> >> Thanks.
> >>
> >> On Thu, Feb 19, 2009 at 3:09 PM, Yuan Zhang <trojanyuan@gmail.com>
> wrote:
> >> > I have found that the declaration of struct ManagedObject and the
> >> > declaration of struct Partial_Reveal_Object are alomost the same. Th=
e
> >> only
> >> > difference is that struct ManagedObject is used in vmcore, and struc=
t
> >> > Partial_Reveal_Object is used in gc, so I have a question: "Does a
> >> > Partial_Reveal_Object pointer in gc always points to an ManagedObjec=
t
> >> object
> >> > in vmcore?". Because I have modified the declaration of struct
> >> ManagedObject
> >> > for some purpose, so if the answer to my question is "yes", I also
> have
> >> to
> >> > modify other codes to make gc run right?
> >> >
> >> > I appreciated any help from you!
> >> >
> >>
> >>
> >>
> >> --
> >> =F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD,
> >> =E1=CC=C5=CB=D3=C5=CA =E6=C5=C4=CF=D4=CF=D7,
> >> http://people.apache.org/~aaf/ <http://people.apache.org/%7Eaaf/> <
> http://people.apache.org/%7Eaaf/>
> >>
> >
>

--000e0cd14cb45fedf704634f7a21--