harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][jit][jet][x86_64] Lazy resolution for JET
Date Thu, 24 Jan 2008 10:11:51 GMT
Gregory, here are the answers to your questions:

On Jan 23, 2008 8:02 PM, Gregory Shimansky <gshimansky@apache.org> wrote:

> The code that contained calls for lazy resolution helpers have
> unbalanced runlock calls when CallSig is not locked, so assertions fail
> that register is not locked.


The patch is correct.


> In call_va function there was no implementation for passing i64
> arguments. I also added a 64-bit version for passing pointer arguments.
>

this is correct.


> Patch also sets lazy resolution mode as default.
>
> Now that I made these fixes some Java code is executed, but Hello World
> doesn't work yet. The problem is with calling
> invokevirtual/invokeinterface resolution helpers. They require "thiz"
> argument as a pointer to the object. The "thiz" value is locked in the
> register at the beginning of gen_invoke method and is unlocked only at
> the end of it. But it so happens that "thiz" may be locked in some
> register that is
>
required to pass arguments to the resolution helper because CallSig is
> locked only before the helper is called. In this case the value of this
> register is overwritten by the arguments of the helper because this
> register is needed for arguments, and therefore the object argument of
> the helper is corrupted.
>

The lock of 'thiz' at the beginning of the method is an old optimization. It
is not correct today.
It does not related to lazy resolution mode and theoretically can cause a
failure for CCONV_MANAGED calls too.
IMO the best solution here is to move global rlock(thiz) into local places
that require ''thiz' to be on a register.

Another problem here: in lazy resolution mode we need to 'vpark' all
registers for CCONV_HELPERS calls too.



>
> I think it is necessary to split this method, it is quite complicated
> and has too many branches to follow so that lazy resolution path and
> normal call path are compiled independently. This will allow to lock
> "thiz" after the helper signature is locked. But I am not very familiar
> with JET, so I am not sure if reordering the locking is the only
> possible way to fix this bug. Could someone from JIT team enlighten me?
>

By splitting the method you have to repeat all the preparation/finalization
for a call in both versions. It's about a half size of the current method.
What do you think by moving the <do_smthX> from

if(meth==NULL) {
   <do_smth1>
} else if (opcod == OPCODE_INVOKEINTERFACE) {
  <do_smth2>
}...

into separate methods?

-- 
Mikhail Fursov

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