Mikhail Fursov wrote:
On 10/13/06, Rana Dasgupta <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
