harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Tanzer <stru...@guglhupf.net>
Subject Re: [arch] VMCore / Component Model
Date Tue, 20 Sep 2005 13:44:45 GMT
Peter Edworthy wrote:
> [Snip]
> 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?

Maybe. I just saw that the APR also provides methods for doing this, so
that would be a good solution too. As i said, my code should only be
a basis for discussion and a proof-of-concept.

> 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?

No, it's not a limitation of the method, the "struct TestComponent*"
could store an arbitrary number of functions.

> 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)?

I'm not sure if we are talking about the same thing here, maybe I just
fail to see some important part of the bigger picture.

My intention was to provide a mechanism with which we could handle
components like the ones for which Weldon Washburn wrote the interfaces
for. For example, it could be used to load implementations of
and interconnect them. It focuses on C (or C++) implementations so far,
I'm not sure if we can easily extend it to support other programming

I think what you are talking about here is more like the "light-weight
native calls" which where proposed by Mladen Turk (correct me if I'm

> 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.

That should be no big problem. I mentioned earlier that it would be cool
if we had several different prototypes we can play with, compare to each
other and discuss about, so maybe someone volunteers for writing one ;-)

> [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

View raw message