Gregory, Let me check and analyze the patch. I'll try to answer your questions today.
On Jan 23, 2008 9:14 PM, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > Gregory Shimansky said the following on 23.01.2008 17:02: > > Hello > > > > Trying to make a correct fix for HARMONY-5322 I tried to turn on lazy > > resolution in JET on x86_64. It didn't work out of the box and I am > > still not finished with fixing it. I attached what I've got already to > > HARMONY-5322 for JIT guys to review since I am not very familiar with > > the code yet. > > > > In short what I've already fixed in VM: > > > > Helpers that perform resolution and receive ManagedObject* have to make > > a check for null comparing against managed_null constant, not NULL. > > > > in JET: > > > > 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. > > > > In call_va function there was no implementation for passing i64 > > arguments. I also added a 64-bit version for passing pointer arguments. > > I forgot one more change. In CodeGen::gen_args I changed rlock argument > from *args[0] to *args[i]. It seems to be more logical and correct > according to comments before the loops. > > > 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. > > > > 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? > > -- > Gregory > > > -- Mikhail Fursov
