[kaffe] Projects/sub-projects dependancies... Thoughts
Guilhem Lavaux
guilhem.lavaux@free.fr
Sun May 16 04:13:02 2004
Helmer Kr=E4mer wrote:
> On Sat, 15 May 2004 18:32:39 +0200
> Guilhem Lavaux <guilhem.lavaux@free.fr> wrote:
>=20
>=20
>>There will be a slight performance loss for JIT=20
>>though: currently the JIT is putting the pointers to translated methods=
=20
>>directly in the vtable. To be compatible with intrp and other way of=20
>>handling methods we must put a pointer to Method.=20
>=20
>=20
> Why do we have to put a pointer to Method into the vtable to be
> compatible? Have you considered modifying intrp so it stores a
I was thinking of the most general approach. That way we could run=20
different engines at the same time. I admit I don't know what is the=20
result on xdebugging (I've forgotten that point); I expect it to be=20
pretty bad. To be able to put the bytecode in the vtable for intrp we=20
will have to change the virtualMachine prototype and introduce a few new=20
structures. For example, virtualMachine will need a bytecode descriptor=20
to execute using the interface described by another Method:
virtualMachine(Method *meth, Bytecode *bytecode, ...)
runVirtualMachine will become:
runVirtualMachine(Bytecode *bytecode, ...)
In the case we want only one engine at a time, your solution may work=20
though the question of the common interface is still here.
Regards,
Guilhem.
> pointer to the bytecode in the vtable (and allocates the bytecode
> so that GC_getObjectBase(address of some bytecode) returns the
> address of the Method* the bytecode belongs to)? And what happens
> to xdebugging when the vtable doesn't contain a pointer to the
> code of the method?
>=20
> Regards,
> Helmer
>=20