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 Wed, 11 Oct 2006 13:10:55 GMT
On 10/11/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> Ivan,
> On 10/11/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> >
> > Mikhail, there is GC<>VM interface function exists for this purpose:
> >
> > Boolean gc_supports_frontier_allocation(unsigned *offset_of_current,
> > unsigned *offset_of_limit) {
> >     // Need additional support for object offset in native stubs.
> >     *offset_of_current = field_offset(GC_Thread_Info, tls_current_free);
> >     *offset_of_limit = field_offset(GC_Thread_Info, tls_current_cleaned);
> >     return true;
> > }
> Yes, I know. But the main benefit of magics is that JIT does not know the
> details of the allocation algorithm.
> The helper is a GC part. You, or any other GC developer, can write any
> fast-path helper you like and point the JIT to use it.
> So my proposal is to use known offset in GC_Thread_Info and hardcode it into
> the helper code.
> Another solution  is to initialize these offsets as final static fields
> during helper class initialization using JNI accessor to GC natives.

Ahh, I see now. I was thinking about GC independent helper. You are right.

> 1. VM exactly knows where the GC_Thread_Info is in TLS and using this
> > offsets can obtain current allocation position and its limit. It seems
> > that the information should be also propagated to JIT if you want to
> > implement the helper inlining.
> Yes, this is not the problem. In the example I wrote the
> TLS.getGCThreadLocal() does the same.


> 2. You should not care about cleaned with uncleaned memory as it just
> > GC v4.1 specific optimization. Fast path should deal with current and
> > limit as in gc_supports_frontier_allocation().
> This is the helper for GCv4.1. JIT does not care if memory cleaned or not.
> JIT does not care if you use bump-pointer of free-list allocation. So it's
> up to you if too keep it.


> 3. This is just VM<>GC native interface function. There is no other
> > parameters passed here currently.
> Yes, it's enough to support GCv4.x and GCv5. But is it OK for MMTK
> collectors? The main idea is to make JIT as independent as possible.

Let's ask Weldon here.

> 4. No need, see above (in 2).
> Ok, if you do not need this functionality in the fast path we can remove it.

Well, if we talk about GC specific helpers, I would prefer to keep it :)

> 5. Excellent idea! I thought about it. This optimization can be much
> > valuable.
> >
> > More issues to deal with.
> >
> > Current native helper which is called from managed code to allocate a
> > object has one problem. It should call <clinit> for uninitialized
> > classes. I was working with it some time ago, but the change was too
> > intrusive and had negative performance impact. It was decided to do
> > this latter. I think we should think about it again now.
> I thought that the problem is already solved on the JIT side?!
> That was a real headache for me to synchronize check sums and map edge
> profiles from the IR with class initialization helpers to IR without it in
> server mode.

It is possible that I have outdated information.

> I suggest before compiling fast path code check whether class is
> > initialized and not finalizible. Depending on the results we can
> > produce different fast (or generic) code paths.
> Finalization issue is clean. But I see no improvements in the fast path
> related to the class initialization.

If we still has issues with initialization we could do the following:

1. If class in already initialized when we compile the allocation code
we can forget about the initialization.
2. If it is not initialized yet, we can insert required initialization
check right before usual allocation fast path.

> --
> Mikhail Fursov

Intel Middleware Products Division

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

View raw message