Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 13 Oct 2006 19:25:54 +1000
From: Robin Garner <robin.garner@anu.edu.au>
Subject: Re: [drlvm] The first GC helper with fast-path implemented in Java:
 gc_alloc
In-reply-to: <bc79dd600610130115q7b769cd9m9378ab12bc4a4d17@mail.gmail.com>
To: harmony-dev@incubator.apache.org
Message-id: <452F5BA2.2080706@anu.edu.au>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <bc79dd600610110257h47d81763s86b3e2a82ba4d35a@mail.gmail.com>
 <9623c9a50610112041t5e1851cek96c15b133d723140@mail.gmail.com>
 <bc79dd600610120144w6378374eq7fbf6b82bf387b36@mail.gmail.com>
 <9623c9a50610122009n7f1eba4cpfe7f40a3cd83a7ef@mail.gmail.com>
 <51d555c70610130055v6a8cd57eq995763a1f0b3cefa@mail.gmail.com>
 <bc79dd600610130115q7b769cd9m9378ab12bc4a4d17@mail.gmail.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060922)

Mikhail Fursov wrote:
> On 10/13/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>>
>> Why is this a problem, am I misunderstanding? Even with conventional
>> helpers, the jit needs to know the helper method signatures. We don't 
>> need
>> to worry about universality of GC's. Any compatible GC will need to
>> implement  exactly the same helper fastpath contract interface as Xiao
>> Feng
>> says elsewhere.
> 
> 
> Yes. The only amendment from me is that JIT does not want to know if GC is
> compatible or not. For example some GC developers may try to implement bump
> pointer allocation by decrementing the offset in a block (like a stack) or
> to do some cleaning like Ivan did.
> But I'm agree with you that our GCv4.1 and GC_GEN could use the same
> fast-path helper.
> 
> I asked this question because of MMTk collectors. It has slightly different
> format of the allocation sequence. If you look into the WB helpers you see
> that the difference is even more than allocation one. IIRC the MMTk WB
> helper needs 4 params to be reported from JIT while our GC_GEN only 2. 
> So we
> have to support in JIT different versions of the same helper.

As far as the MMTk 'alloc' method goes, MMTk is simply providing 
flexibility that you don't need to use if you don't want to.  The Java 
helper can supply default values for alignment and allocator, and MMTk 
won't mind.

The barriers are slightly different.  We require the Source object, 
target object and slot in order to a) be a substituting write barrier, 
b) implement object-remembering barriers, c) implement reference 
counting.  The fourth parameter differentiates between ASTORE, AASTORE 
and PUTSTATIC barriers, and again if you only have one of these (or take 
the same action in all cases), a hard-wired default will do.

If there's a really good reason you can only supply slot and target, 
some of the MMTk generational collectors (eg GenMS) will work, but some 
of the more interesting ones like GenRC won't.

> 
>> I don't think that the jit  needs to know that an object being 
>> finalizable
>> implies not to invoke the fastpath. This to me suggests that the jit
>> determines allocation policy. I don't see a problem passing the object
>> typeinfo or allocation handle to the helper. It is needed for object init
>> anyway.
> 
> 
> Doing isFinalizable check during a compile time instead of runtime looks
> like a reasonable optimization to me.Moreover, once you want to do it in
> runtime, you have to add special magic isFinalizable(type). So we can add
> such an option (configurable from the command-line or property file) to the
> JIT.

There are reasons why the JIT might want to - if not control, then at 
least influence - allocation policy.  Pretenuring is one optimization 
that comes to mind.

One advantage of controlling allocation through method parameters is 
that if they are statically resolvable, they are easy for the compiler 
to optimize out after constant propagation.  Having the compiler 
specialize code that involves (eg) looking up an allocation handle is a 
much bigger ask than checking a bit in a parameter.  MMTk takes 
advantage of this quite a lot - the allocation fastpath of a typical 
plan may look impossibly heavy at first glance, but in most cases it 
optimizes out to a handful of instructions.

Designing the interface in a way that appears like you are dynamically 
checking for finalizability(is that a word?), coupled with some constant 
folding and dead code elimination can give you the best of both worlds. 
  It allows you to implement compile time optimization (in which case 
inlining, constant folding, dead code elimination etc do the work), but 
also gives you the opportunity to implement initially a slow way, and if 
there are infrequent difficult cases, leave them as runtime checks.

cheers

-- robin


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