harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Wed, 11 Oct 2006 12:31:50 GMT

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.

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.

4. No need, see above (in 2).

Ok, if you do not need this functionality in the fast path we can remove 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.

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.

Mikhail Fursov

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