Mikhail, I wrote my reply before read yours. :-)
On 8/16/06, Mikhail Fursov <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
