Yes, this two parts solution probably is necessary. We don't need to be purists to constrain ourselves.
Thanks, xiaofeng On 1/24/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 1/24/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > On 1/23/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > On 1/23/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > > > > > > Based on my prior experience with M2N frame work, I have the same > > > feeling that compiler instrinsic might be able to deal with fast > > > native call (except some corner cases where very special calling > > > convention ect. is used, e.g., the native method itself is a > > > hand-written asm code sequence.) > > > > > > Probably the compiler instrinsic semantics can be expressed with Java > > > Magics, then they are just the same thing from different viewpoints. > > > > > > > > The problem is with usual JNI calls. JIT knows nothing about M2N frames > > today. Pavel wants to encode JNI stub's body with magics and do not add > any > > knowledge about M2N into JIT. > > Yes, I see his point. I wonder what is the main benefit. Is it to save > the two "call" instructions? Inlining help us not only avoid 'calls' but also give a chance to propagate parent method data into inlined methods. Sometimes even 1 extra call elimination is worth to do. For example, removal of call for monenter helper gave ~5x speedup on microtests. > So we have 2 new magics: allocateMemChunkOnStack(size) and > > saveRegisters(Address, howToSave) > > The problem left is EIP handling. Before making direct call JIT pushes > > call's args, saves caller-save regs, so EIP changes. > > When unwinding native call VM uses EIP saved in M2N frame. JIT can't > find > > call by this EIP and this is the problem. > > I'll take a break here for a day to think more about it and read others > > ideas how to deal with EIP... > > > > Go with the compiler intrinsic approach, JIT doesn't have to compile > the stub code blindly as common magics. It knows the stub is for fast > native call, then it can intelligently emit code to handle EIP. > Annotation or pre-generated asm sequence may help. > > Well, we need judge if it's worth doing with the complications. Intrinsic approach has one drawback: there can be a lot of info in M2N frame that JIT does not want to know. With help of magics we can try to split M2N stub into 2 parts: 1) Custom part: here VM developer can link M2N into the list, save method handle, check for exceptions, do anything else VM need. 2) General part: this the intrinsic you mentioned. JIT must save registers into the specified area and generate a call. In the case 2) we can use the approach proposed by Pavel above and add the method like: callNative(Address nativeAddr, Address m2nRegSaveAddr, Params..) where m2nRegSaveAddr points to the area allocated on a stack Another problem is how to pass params (number of params? types?). Any ideas? Pavel? Xiao-Feng, did I miss something from your proposal about intrinsics? -- Mikhail Fursov
