harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Thu, 12 Oct 2006 11:21:38 GMT
On 10/12/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> On 10/12/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > On 10/11/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > GC, VM gurus!
> > >
> > > The problems I see:
> > >
> > > 1) The problem: GC helper must know GC_Thread_Info struct offsets.
> >
> > This is no problem. I designed fast-path allocation that is
> > independent from specific GC in GCv5, I have no GC_Thread_Info because
> > the name is confusing. I use Allocator structure for it, which is
> > defined as:
> >
> > typedef struct Allocator{
> >   void *free;
> >   void *ceiling;
> >   Block *alloc_block;
> >   Space* alloc_space;
> >   GC   *gc;
> >   void* thread_handle;   /* This thread; */
> > }Allocator;
> >
> > The values of the fields offset are constant; and for fast path, only
> > free and ceiling are needed actually.
>
>
> Ok, no new functionality is required to write a fast-path helper for gc-v5.
>
> > 2) The problem: Where to keep GC magic code? This code is GC specific and
> > > must be available for bootstrap classloader.
> > > JIT can know all the details which magic code to inline (the helper
> > type,
> > > the helper signature) from its properties (see opt.emconf file for
> > example)
> >
> > The code definitely should be part of GC since it's developed by GC
> > developer. The contract between GC and VM (not JIT normally) can be
> > accomplished in way similar to current RT helper support (not the same
> > of course). We can put all the helpers into a single class (the
> > contract interface), so that each GC implementation can inherit the
> > class with its implementation. The non-overriden (or implemented)
> > methods will not be inlined.
>
>
> Xiao-Feng, do I get it right? The "contract interface" is:
> The implementation of helpers are static methods with known names.
> Every GC puts the implementation of its helpers into the separate
> package/class and JIT knows the name of the package/class from a properties.
> Or do you mean something different?
>
>
> > 3) The problem: Is the signature for gc_alloc method : gc_alloc(int
> > objSize,
> > > int allocationHandle) is universal for all GCs?
> > > I think it's not. But we can extend JIT with different signatures
> > support if
> > > needed.
> >
> > This interface has a third parameter of TLS for gc. Are we going to remove
> > it?
>
>
>
> Yes, because TLS value is needed for different helpers. So, the better
> solution could be is to have TLS.getAddress() as magic.
>
>
> On the other hand, I prefer to ignore the allocationHandle parameter
> > in fast path. We don't really need it anyway.
>
>
> Storing type info into object image is a part of the object initialization.
> This way old slow helpers work. Do you propose to change the old slow
> interface and ask JIT to initialize object image?

Keeping in mind that we use allocation handle to initialize allocated
memory chunk. There is one more need for it - to pass it into slow
path - to distinguish finalizible and not finalizible objects during
allocation. A different solution can be used for this - separate
helper for non-finalizible objects allocation (+1 from me here).

--
Ivan

>
> > 4) The new magic method is proposed, line J21:
> > > org.apache.harmony.vmhelper.native.Utils.memset(tlsNewFreeAddr,
> > > bytesToClean, 0);
> >
> > What magics you want to implement are completely your freedom. :-) But
> > personally I prefer not having memset in magics. It's way too system
> > dependent. If we want it for GCv4.1 performance reason, we can keep
> > this kind of non-essential methods into another extra interface.
>
>
> No, it's not mine (as  JIT developer primary) freedom. We are discussing VM
> extension for magics and must avoid any unnecessarily operations.
> Why do you think memset is bad and system dependent primitive?
>
> > 5) The magic code in does not contain 'finalizable' check.
> > > JIT can do this check during the compilation and do not generate the
> > fast
> > > path. This is another option to pass to JIT from GC.
> >
> > Yes, this is good. Let's drop the allocationHandle. I am not using it in
> > GCv5.
>
>
> Here I have the same question as above. How do you initialize a raw object
> image? (I'll take a look by myself, it's very interesting problem)
>
>
> --
> Mikhail Fursov

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message