Weldon Washburn wrote:
Robin,
I really like your thinking! I would like to see Harmony drlvm support
MMTk
fully. this may take a while. Please feel free to keep pushing to do the
right thing with the JIT.
Well, with this encouragement, there are a few more things I'd like to
suggest:
- Rather than make TLS access be a magic, how about defining an object
with fields that point to all the VM resources (such as TLS) that a
helper wants, and then calling the helper as an instance method of that
object ?
. If devirtualisation of this is problematic for the JIT at the
moment, perhaps introduce a magic pragma instead of the TLS access handler
- Mikhail's prototype Java helper looks like C transliterated into Java.
This is reminiscent of the very early days of JikesRVM. IMO, you
should actually use Java here rather than fight it ... define an
abstract Allocator class, and a concrete BumpPointer instance for example.
One of the lessons of MMTk was how much you can trust the compiler, and
each revision uses more and more object orientation. You guys are in an
ideal position, because you have control over the compiler as well as
the java code.
cheers
On 10/13/06, Robin Garner <[EMAIL PROTECTED]> wrote:
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]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
