Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of ivan.volosyuk@gmail.com
 designates 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=pmq3ztg1/KTa5p3CyLOZ5BHwkIeL8dQtN+DHrVt+cad58PG1a4wR3LKKRtOu9TF7gGLPqw+N0rzwPn0JNSVdO+Rd7d69hGiiSujfiB3VZusb/otI71AMHigxLBA52eITCDFn40JS9mFfgEp/NR+upgSlLj4z9U1HCCCicpc/+gg=
Message-ID: <12385bbd0611021808v6cf091bch351968ef1ff79635@mail.gmail.com>
Date: Fri, 3 Nov 2006 05:08:55 +0300
From: "Ivan Volosyuk" <ivan.volosyuk@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][sablevm] Desing of Class Unloading Support
In-Reply-To: <9623c9a50611012346p79528621jd5e043fa88c7bfbe@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com>
	 <51d555c70610311454s24d2089cx7eeb9af17d7ebfaf@mail.gmail.com>
	 <bc79dd600611010020n75ab087bm412f32c9ea757aca@mail.gmail.com>
	 <u1wona3sj.fsf@gmail.com>
	 <bc79dd600611010157m1e0def1eg82f9334c787969f9@mail.gmail.com>
	 <uwt6f8osq.fsf@gmail.com>
	 <bc79dd600611010246jcf6606cn50c769447dfca035@mail.gmail.com>
	 <9623c9a50611010304s33a1ff00u928847ed8a161fc@mail.gmail.com>
	 <454985C0.1090501@anu.edu.au>
	 <9623c9a50611012346p79528621jd5e043fa88c7bfbe@mail.gmail.com>

On 11/2/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 11/2/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> > Xiao-Feng Li wrote:
> > > On 11/1/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > >> On 01 Nov 2006 16:05:41 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> > >> >
> > >> > On the 0x214 day of Apache Harmony Mikhail Fursov wrote:
> > >> > > On 01 Nov 2006 15:56:28 +0600, Egor Pasko <egor.pasko@gmail.com>
> > >> wrote:
> > >> > > >
> > >> > > > agreed. not patching .. just reporting 'golden' VTable refs to
> > >> GC, am
> > >> > > > I right?
> > >> > > >
> > >> > > Yes, and everytime we report it to GC and GC moves an object - it
> > >> > patches
> > >> > > the address we report.
> > >> >
> > >> > so, by saying "patching" you insist to put immediate operands into
> > >> > instructions? That's probably worth it, but it extends the JIT<->GC
> > >> > interface. How about making a simple operand (reg/mem) as the first
> > >> step?
> > >>
> > >>
> > >> Egor, I thinks this is slightly more complicated problem. If vtable
> > >> object
> > >> is moved we must update all devirtualization points in every method
> > >> compiled
> > >> before. It can require an extension of JIT<->VM<->GC interface.
> > >> Another solution I see is to collect info about all devirtualization
> > >> points
> > >> in JIT (code addrs) and report these addresses as enumeration roots.
> > >> This is
> > >> JIT-only solution, and disadvantage is a significant (~hot methods count)
> > >> increase of number of objects reported.
> > >>
> > >> On the other hand I see no reasons to unpin vtables in the nearest future
> > >> (Let's GC guru correct me). If you use special (freelist-type ?)
> > >> allocator
> > >> in GC the memory fragmentation when unloading pinned vtable objects
> > >> could be
> > >> low.
> > >
> > > Yes, vtable should never be moved except for very weird reason. And
> > > yes, to pin certain amount of objects is not a big performance issue
> > > (in both temporal and spatial wise).
> > >
> > > -xiaofeng
> > >
> > >> --
> > >> Mikhail Fursov
> > >>
> > >>
> >
> > In MMTk, this kind of 'pinning' is an allocation-time policy decision of
> > the type I was advocating in the GC helpers thread.  Once a GC allows
> > for the idea of supporting multiple collection policies (which
> > generational GC requires in any case), then adding a non-moving space to
> > a memory manager is easy.
> >
> > Most memory managers will have a non-moving large object space no matter
> >   what the primary collection policy is.  The DRLVM collectors have this
> > too, don't they ?
> > Pinning an object after allocation is a harder problem, but not
> > something required in this case.
>
> Yes, I agree with all what you said. And DRLVM GCv4/v5 doesn't move
> large objects at the moment.

GCv4.1 does. There is no problems to support pinned allocation here anyway.

-- 
Ivan
Intel Enterprise Solutions Software Division