MIkhail, I have some questions, or just arguments :-) First, though it is nice to talk of an open helper inlining framework to call VM/GC helpers, isn't the set of helpers used in JVM's more or less well known and standardized? In other words, is a framework absolutely necessary, can't the jit just generate code inline for the known fastpath of the helper algorithm? For example if we replaced the DRLVM gc with gc_new , how many new helpers do you think we would introduce?
Also, please see below for some inline comments... On 8/11/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>Even this simple helper reveals a lot of features to support: >1) Access to TLS is required. It could be fs:[14h] on Windows or helper call >on Linux (depends on kernel (?) ). Even if we have an access to TLS we need >to know the offsets of our slots: 'current' and 'ceiling' in example. >So we need to have a way to pass these values to JIT. May be a 'private >static final' variables in the helper's class with special runtime >annotations could be used to pass the values to JIT?
So basically, every new VM would need to implement the helper in an almost identical way or at least using identical final variables...I wonder how much flexibility that leaves ..
2) Calls support is needed. Both for "slow" helper version and to access >TLS. >This means also that calling convention support is needed. Runtime level >annotations for helper calls could be used here. E.g. create a magic method >'slow_alloc' and teach JIT to call real helper instead of it. Get the >calling convention info from annotation (?)
Is it not possible for the fastpath helper to just return a failure so that the jit generated conventional helper callpath can kick in. In other words, does the slow helper have to be called from the fast helper?
3) Do we really want to expose native regs to Java: EAX, ECX... I vote do >not to use them when writing helpers in Java and to allow to JIT to optimize >unboxed operations (allocate registers by itself)
This again goes back to my original question...if the JIT knew the standard fastpath, it could generate code optimally for it anyway with the best use of registers? These are just arguments before we set off developing a framework. I would like to know if helpers vary a lot across VM implementations, seems to me they need to do the same old things. Even if a framework is needed, it seems that we will land up inventing a language with unboxed primitives, virtual register access and special calling conventions for it to work optimally. And then we want every VM to use this language to code fastpath helpers and also to code the slower helpers in the conventional way. Maybe we should ask VM developers to vote on how open this is.... Thanks, Rana
