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] Helper inlining in JIT
Date Wed, 16 Aug 2006 08:52:54 GMT
Mikhail, I wrote my reply before read yours. :-)

On 8/16/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> The separation is not clean if there is a helper that we can't write in
> Java. Once we added TLS and native calls support to Java I can't imagine
> this helper today, but I'm still looking for it :)

I guess Rana's question on framework is more about the decision making
about inlining and the service routine interface. I replied in my last
email.

> Yes, this is a good point to start. The information about native method's
> calling convention (slow helper)  can be stored as annotation for the
> method. Here is an example from Xiao-Feng:
>
> Reference object_alloc(int size, Address vtable ) {
>       Reference result = ThreadLocalBlock().alloc(size) ;
>       if( ! free.isNull() ){
>            result.setAddressAtOffset(vtable, VTABLE_OFFSET_IN_OBJECT);
>            return result;
>       }
>       //native slow path
>       return object_alloc_slowpath(size, vtable);
> }
>
> and object_alloc_slowpath() is the native version of the slow helper.
>
> We can add Java method to the same Java class:
> private static Reference object_alloc_slowpath(int size, Address vtable)
> and annotate it something like this
> @NativeHelper{"helperName=slowAlloc", callingConvention="cdecl",
> enumerationPoint="true"....}

Good! This is related to a point in my last email about "freedom to
the developer". Annotations can be used to make JIT inlining much
easier.

>
> What is the difference of unsafe intrinsic and asm helper?
>

Good question. :-) I think it's more conceptual or a design logic.

1. intrinsic is JIT-domain entity, the helper in DRLVM is VMCore
entity. It can be written in whatever IR that JIT prefers.
2. insinsic code provider. Thread-local-storage is more a VM concept
but used by JIT, since a JIT developer is unlikely wanting to know how
TLS works in underlying OSes. As stated in 1 above, we prefer JIT to
hold all the intrinsics in its domain, that means we need some
agreement between VM and JIT for TLS access.

In reality, they can be very similar. :-)

> AFAIU  it's  enough to annotate JNI method with calling convention details
> and to support it in JIT and VM.  So I see no difference in implementation
> with helper inlining here. Just an extension or another version of helper
> inlining mechanism.
> Am I missing something about JNI support?

Yes, I guess you were missing something. ;-)
The service routine inlining is to attack the performance issue
brought when Java code calls into VM native services. If the JNI is
not a problem, this Java inlining can be not very interesting.


> AFAIK Weldon and Alex made a lot of work related to support of unboxed types
> in DRLVM.
> We can reuse their work to prototype the inlining of the first helper's fast
> path in Jitrino.JET (it's easier) and after it succeed port the code to
> Jitrino.OPT compiler.

Agreed. I mentioned the same thing in my last email.

> Is new object allocation helper OK to start from? Any other ideas which
> helper to use to start?

I think it's a good idea.

Thanks,
xiaofeng

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


Mime
View raw message