harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [drlvm][jit][jet][x86_64] Lazy resolution for JET
Date Wed, 23 Jan 2008 15:14:57 GMT
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?


View raw message