harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Edworthy" <pe...@edworthy.org>
Subject Re: [arch] VMCore / Component Model
Date Tue, 20 Sep 2005 11:38:35 GMT
Hi,

sorry if this is a bit long, my fault for not catching up with the list
for a few days ;-}>

headlines are:

* Cross-platform and language support
  - ltdl vs dlfcn
  - native code needed to access native code, jikes boot strap system
  - Java based loader?

* In-lining of code
  - let the JIT do it

* native code storage for JIT use
  - how much information is needed to allow good optimization?

[cross-platform support]

First of all thanks to David Tanzer, having something solid to start from
makes a tremendous difference. The code captures a basic functional spec
for a component loader very well.

I'm not very familiar with UNIX dynamic libs so if this is way off please
say;

It seems dlfcn is quite platform specific; would ltdl make more sense?

It seems as though only one 'native method' is provided per file this way,
is that just for the demo code or is it a limitation of this method?

Am I right in thinking that to use the table of 'native method' pointers
we will have to place the operands on the stack and then jump to the
method (just checking as the code to do that would also be a component and
so how would we bootstrap it, jikes had a clever method involving writing
from a JVM a startup JVM image with the native code in it)?

Could this be implemented in Java so long as a native call mechanism
existed to 'register' components with each other, there is probably no
compelling reason to do this but it might improve cross platform support.

[Code-In lining]
To have a JIT we must have a method of storing 'compiled code' and calling
it we could create the basic components as native code stored in the JVM
using same system as the JIT. The class loader could then mark inside the
byte stream a call to this native code in place of the original byte code.
Or the interpreter could act as though the byte code should be interpreted
as a call to that method.

If this is too inefficient then the JIT will compile the method that the
call is within and at this point may well decide to in line the code from
the method call.

I don't see why we would want to or need to create a different in lining
method for these aspects of the interpretor. If we are using the boot
strapping method like jikes then maybe some methods should be JIT'ed
before the image is written.

[native code storage for the JIT]
I've never tried to create a JIT, but I assume we need to consider some
way of describing the side-effects of a section of code; i.e. what
registers are changed/used as input and output.

Or do JITs not normally need this as they compile whole methods and so use
the stack for data in and out and assume all registers are dirty?

Thanks in advance,
Peter


Mime
View raw message