harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Thu, 12 Oct 2006 03:41:57 GMT
Mikhail, thanks for the hard work.  Ivan has given some good comments.
Please see my late comments below inlined. Thanks, -xiaofeng

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; */

The values of the fields offset are constant; and for fast path, only
free and ceiling are needed actually.

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

> 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 think this interface is good enough at the moment.

On the other hand, I prefer to ignore the allocationHandle parameter
in fast path. We don't really need it anyway.

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

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

> I've enumerated the lines in code if you want to comment it.
> Please feel free to review the code and to discuss any other problems I
> missed.
> --
> 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

View raw message