harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Fri, 13 Oct 2006 04:41:50 GMT
On 10/12/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 10/12/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > 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?
> Yes. I guess it's possible for the gc_init() to pass the related info
> (properties) to VM, then JIT can query VM for them.

I am OK with the above as long as there is an "#ifdef PROTOTYPEVMMAGIC" kind
of a demarcation.  The main concern is to not be too casual about dumping
stuff into GC/JIT/VM interface that ultimately becomes a maintenance

> > 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?

I really recommend against removing this parameter.

> >
> >
> > Yes, because TLS value is needed for different helpers. So, the better
> > solution could be is to have TLS.getAddress() as magic.
> Ok, thanks, makes sense. Then this TLS.getAddress() probably can have
> a parameter like TLS_FOR_GC, so that it can be a little bit more
> flexible. Well it's only syntactical suger anway.

I really like the simple "Address thrloc  = TLS.getAddress();" api.
Otherwise we end up adding ...getAddress(Offset) and ...getAddress(Extent)
and ...getAddress(Word), etc.  If we don't add these APIs, we end up having
to continually explain why they are missing, etc.

To access a member of the tls data struct we can use the existing vmmagic
intrinsics.  For example:

   Offset ofs = Offset.fromInt(TLS_FOR_GC);
   Address gcStruct = thrloc.loadAddress(ofs);

> > 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?

hmmm... the vtable ptr has to be written to object header somewhere between
GC allocation and first object use.  I don't see how moving around the point
of this write can make any performance difference.  However, if someone
shows convincing performance data, it would be a different story.

Ok, I get back this suggestion. :-)  Although it's a simple store
> operation in gc_alloc_fast, it is still better to keep the semantics
> clear that the object image initialzation is GC's task rather than
> JIT's. And the helper inlining will actually optimize the parameter
> passing away, so it's not overhead at all.

Yes, exactly!

> > 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?
> Ok, this is not a trivial topic. Some of my cents:
> Firstly, magics. From the design idea of magics for Java, we want to
> keep the set as mimimal as possible, since they are just to enable
> Java to do something impossible. memset is not language construct,
> it's a library function. We don't want the magics to be a fast path
> for random native function calls. For example, memset is to store
> values into a memory region, it can be implemented as storing the
> values into a byte array in Java (perhaps with magics).
> Secondly, the helpers. JIT does helper inlining to speedup the system,
> not to break the modularity. It's not JIT's task to do any memory
> management. JIT should know mimimal (or nothing) about other
> components' functionalities. It does inlining and only inlining.

Agreed.  The JIT should not be a dumping ground for misc undocumented
premature optimizations.  Please focus on getting the inlining to work
correctly.  Focus on the performance of inlined vs. non-inlined code.  Does
the JIT generate the best code sequence?  Does the global optimizer do the
best optimization once the alloc() sequence has been inlined?

memset is not supposed to be inlined for a VM written in C, and
> probably not either in a VM written in Java except it's written in
> Java itself.
> Thirdly, fast native call. memset is a native function, hoping to be
> executed as fast as possible. In this case, we probably better employ
> the mechanism of fast JNI rather than magics. Since fast JNI actually
> is available in the VM, we have no strong argument not to use it for
> memset.

As Xiao Feng mentions, memset() is filled with a bunch of complications.  We
do not want to dive into writing yet another highly optimized memset()
library.  There are plenty of them on the shelf.  I would like to set
memset() aside and stay focused on showing perfomance data on inlined
alloc() at this time.

> > 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)
> I took back this suggestion above. (Well, the initialization is a
> simple value store.)

Since the above is rather difficult to follow.  Please confirm that the GC
is *still* responsible for installing the vtable pointer.

> xiaofeng
> ---------------------------------------------------------------------
> 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

Weldon Washburn
Intel Middleware Products Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message