harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm][magic] New Magic features proposal.
Date Tue, 23 Jan 2007 17:06:49 GMT
Oh. I see.

When m2n frame created on the stack in runtime helper, eip isn't pushed into
stack. It's already here, it's return address. So in eip may be pushed code
address of nearest call or just after it.

Also I can propose to use fastNativeCallByAddr(methodAddr, eipValueAddr,
args). So  eip can be updated during calling.

Pavel Afremov.

On 1/23/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> On 1/23/07, Xiao-Feng Li <xiaofeng.li@gmail.com> 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.
> 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...
> --
> Mikhail Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message