You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2005/06/22 18:55:11 UTC
[modules] classloader/jit interface
All,
I'd like to start interface design discussions. Probably the simplest
interface to start with is the API between the classloader and the
JIT/interpreter. Another reason to start with this interface is
because Harmony will need to be able to parse a *.class file before we
do much of anything else.
I have been looking at our current VM implementation which derives
from a research project called ORP. Roughly, the major categories in
the classloader/jit interface are:
- register JIT callbacks (e.g., notify the jit when a given method is
overridden)
- class info (e.g., what is the superclass, which package…)
- method info (e.g., exception info, get_max_stack, pointer to start
of bytecode…)
- field info
- resolution (e.g., find the hard address for a static in a
yet-to-be-loaded class)
- access flags for Class, Field, Method
I'd like to see harmony-dev develop detailed APIs for the above. I
think we should be able to do this within 1-2 months.
Thoughts?
-- Weldon
Re: [modules] classloader/jit interface
Posted by Weldon Washburn <we...@gmail.com>.
Tom,
Thanks for being on topic. This thread has drifted all over the place.
I wasn't thinking clearly on the proposed interface. Your suggestion
is the correct way to go. I was originally thinking that the below
interface would be macros that are used to pull the relevant bits out
of the "modifier int". I now realize that the below looks like a
virtual method call on instances of class/method/field... oops...
I will take another stab at the modifiers API and also pick another
aspect of the JIT/Classloader interface for discussion. Maybe
class_lookup_field_recursive...
On 27 Jun 2005 09:30:01 -0600, Tom Tromey <tr...@redhat.com> wrote:
> >>>>> "Weldon" == Weldon Washburn <we...@gmail.com> writes:
>
> Weldon> Below is a first stab at the API to retrieve the values
> Weldon> contained in internal classloader data structures.
>
> Weldon> Comment/questions are appreciated.
>
> Weldon> Class access and property modifiers (table 4.1)
> Weldon> bool Class::is_public(); // ACC_PUBLIC
> Weldon> bool Class::is_final(); // ACC_FINAL
> [ ... ]
>
> Why not have a single API for retrieving all the flags encoded as a
> word? We already need this capability to implement things like
> Class.getModifiers. The flag values are unlikely to change, and we
> won't even have to code them in the source anyway (we can generate
> them from Modifier.class).
>
> Also, it is worth clarifying whether, for Class, this returns the
> "real" modifiers or the modifiers from the InnerClasses attribute.
> The former are typically needed internally but the latter are needed
> in some situations (Class.newInstance I think).
>
> Tom
>
Re: [modules] classloader/jit interface
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Weldon" == Weldon Washburn <we...@gmail.com> writes:
Weldon> Below is a first stab at the API to retrieve the values
Weldon> contained in internal classloader data structures.
Weldon> Comment/questions are appreciated.
Weldon> Class access and property modifiers (table 4.1)
Weldon> bool Class::is_public(); // ACC_PUBLIC
Weldon> bool Class::is_final(); // ACC_FINAL
[ ... ]
Why not have a single API for retrieving all the flags encoded as a
word? We already need this capability to implement things like
Class.getModifiers. The flag values are unlikely to change, and we
won't even have to code them in the source anyway (we can generate
them from Modifier.class).
Also, it is worth clarifying whether, for Class, this returns the
"real" modifiers or the modifiers from the InnerClasses attribute.
The former are typically needed internally but the latter are needed
in some situations (Class.newInstance I think).
Tom
Re: [modules] classloader/jit interface
Posted by Steve Blackburn <St...@anu.edu.au>.
> Research and proven results are not and must not be mutually
> exclusive. To the contrary!
I really want to drive this point home.
Researchers who do not value good engineering are doomed to short lived,
unrealistic infrastructure, undermining the credibility of their
research. This is an all-too-common trap in academic research.
Engineers who do not value good research are doomed to designing second
rate outcomes. In my experience this happens far too often in open
source projects.
Harmony seems to be a real opportunity to turn this around, combining
good research with good engineering. The complexity of a modern VM and
the quality of current commercial VMs leaves us with little choice if we
really want to compete.
--Steve
Re: [modules] classloader/jit interface
Posted by Steve Blackburn <St...@anu.edu.au>.
Hi Rafal,
My guess is that there are a dozen people on this list right now who,
given a month, could build a simple VM from scratch, on their own.
However, building something like ORP or Jikes RVM is an enormous task,
well beyond the scope of any individual.
In other words, I don't think the challenge we collectively face is that
of identifying the right abstractions for a simple VM---this is
relatively simple. My feeling is that the real task in front of us is
designing and implementing a VM core which can support the ambitious
goals of Harmony---this is a challenge.
As I've said in previous posts, I think that looking at clean, simple
VMs such as Jam VM will be invaluable to this project.
However, clean abstractions made in the context of a simple VM goes to
pieces once the complexities of aggressive optimizations and pluggable
generality come into the picture. A great example of this is the
hardness of retrofitting GC maps into a VM. GC maps are essential to
high performance GC, but are often overlooked in simple VM designs and
yet retro designing them is an enormous task. Likewise object model
optimizations, method dispatch, stack frame organization, etc etc all
wreak havoc on more basic abstractions.
I don't think we're that far away from being able to build a new VM
core. We have so much at the table. My hope is that we could have our
own VM core with a simple interpreter or JIT and perhaps a naive GC
could be up and working in a matter of months. I am also a strong
believer in being prepared to throw early implementations away. If we
try to get our first implementation perfect first shot, we're sure never
to have a first implementation. On the other hand, we should certainly
try to make the most of the experience we do have at hand, so that our
first implementation is not too wildly off the mark.
A few more detailed responses:
>- it is important to distinct between innovation/research and good
>engineering.(eg mono
>
Innovation/research and good engineering are absolutely not in
opposition!! Good engineering is KEY to good research.
> well engineered framework
>shall make research easier after all; that is why I'm rather a
>C-camper
>
What is the connection between good engineering and the use of C? I
don't follow.
>make sure to make it efficient as some operations (write
>barriers, for example) are critical when it comes to performance;
>
>
Please see previous posts on this subject. Fast barriers probably need
to be written in Java or compiler IR, not C (this is because they are
injected into user code and need to be optimized in context).
>- avoid prematurely sacrificing design for the sake of performance;
>
>
Agree 100%
>- Java-C/C-Java (internal) interface doesn't necessarily have to be
>slow;
>
Anything that involves a function call is "slow" in the context of many
aspects of VM implementation. This is fine for coarse grained
interfaces, but unacceptable for fine grained interfaces such as the
allocation and barrier paths. Careful design should make the
integration of C & Java modules possible (just avoid interface
transitions on the fast path).
>- having some kind of 'frankenVM' consisting of various pieces doesn't
>have to be inherently bad; did Mono emerge this way or am I wrong ?
>
>
A VM that draws on the enormous investment at hand by taking a JIT from
here and a memory manager from there is a very wise choice.
>- someone has to build a 'big picture' and split it into parts to make
>people working on details (don't start with one or two interfaces,
>start with a big picture first: several main modules, how shall they
>interact with other modules, where are potential problems); that HAS
>to be done by a person with extensive experience in VM construction
>(engineer rather than researcher); newbies like myself fall short in
>this mainly because of not having dealt with details;
>
>
I agree with this very strongly, however I don't think it should be one
person---it should be done collectively.
>- sorry for being a bit offensive on researchers ;) it wasn't my
>intention, I just think that we need to have a proven set of things
>first, then may do some good research on it;
>
>
OK. I'm offended ;-)
In all seriousness, you need to understand that the state of the art in
VM design and implementation is coming out of researchers and research
labs. Research and proven results are not and must not be mutually
exclusive. To the contrary! As far as I know, as far as "proven"
results go, the two best performing open VMs are ORP and Jikes RVM, both
of which have come out of research labs. Good engineering is at the
heart of good research---I believe the opposite to be true too.
--Steve
Re: [modules] classloader/jit interface
Posted by Steve Blackburn <St...@anu.edu.au>.
Hi Kazuyuki,
>>I guess that the reason why Jikes RVM does not have an interpreter is
>>mainly its implementation language Java, not for performance:
>>
>>
Not really. JRocket makes the same choice.
One argument is that it is simpler to have a compile-only infrastructure
rather than one that can deal with both compiled execution and
interpretation. If the cost & performance of baseline compilation is
comparable to interpretation then the advantage of a single mode of
execution could be worthwhile.
>>Imagine us implementing an interpreter in Java language. We need
>>another Java runtime to execute the interpreter, otherwise the
>>interpreter has been compiled into native code. A Java runtime should
>>be self-containing (except bootstrapping) and then the interpreter has
>>to be compiled. We have to implement a compiler in advance of an
>>interpreter.
>>
>>
>
>Can we use a pre-existing AOT compiler like GCJ to compile our
>interpreter? It will be difficult because compiled code has to be
>compliant with the internal structure (e.g. execution engine
>interface) of targetted Java runtime and other AOT compilers do not
>comply with it.
>
>
On a platform for which we support optimized compilation, say IA32, then
of course we have our own compiler with which we can compile the
interpreter. On a more obscure platform for which Harmony does not have
an optimizing compiler, then this presents a problem.
I see at least three solutions to this problem:
1. Write the interpreter in C and depend on gcc's portability.
2. Write the interpreter in Java and depend on gcj's portability.
3. Leverage gcc or gcj to automatically build a (non-optimizing)
compiler back end, and then use that.
Step 3 is an adaptation of the approach used by Gregg and Ertl for their
portable forth VM. This appeals to me.
--Steve
Re: [modules] classloader/jit interface
Posted by sh...@computer.org.
From: shudo@computer.org
> I guess that the reason why Jikes RVM does not have an interpreter is
> mainly its implementation language Java, not for performance:
> Imagine us implementing an interpreter in Java language. We need
> another Java runtime to execute the interpreter, otherwise the
> interpreter has been compiled into native code. A Java runtime should
> be self-containing (except bootstrapping) and then the interpreter has
> to be compiled. We have to implement a compiler in advance of an
> interpreter.
Can we use a pre-existing AOT compiler like GCJ to compile our
interpreter? It will be difficult because compiled code has to be
compliant with the internal structure (e.g. execution engine
interface) of targetted Java runtime and other AOT compilers do not
comply with it.
Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
Re: [modules] classloader/jit interface
Posted by sh...@computer.org.
From: Rafal Lewczuk <ra...@gmail.com>
> Things like ORP (and propably Jikes - not
> sure) are intentionally omitting interpreter, relying on a fast,
> non-optimizing JIT instead. I don't know but it may affect some design
> decisions. Assuming that framework = set of interfaces (for example
> GC) + set of conventions (for example, stack layout), discarding
> interpreter part in a server VM may lead to more opportunities in
> optimizing VM.
I guess that the reason why Jikes RVM does not have an interpreter is
mainly its implementation language Java, not for performance:
| Subject: Re: Other interesting papers and research
| Date: Mon, 06 Jun 2005 21:34:44 +0900 (JST)
| For Java-written JVM, it seems to be natural to have a baseline
| compiler instead of an interpreter.
|
| It looks complicated to have an interpreter for a Java-written JVM. We
| hope that the architecture of a JVM (e.g. interpreter or baseline
| compiler) is independent of the language for implementing a certain
| part of JVM. But there seems to be an implication between them.
| Any comment?
Imagine us implementing an interpreter in Java language. We need
another Java runtime to execute the interpreter, otherwise the
interpreter has been compiled into native code. A Java runtime should
be self-containing (except bootstrapping) and then the interpreter has
to be compiled. We have to implement a compiler in advance of an
interpreter.
We will first implement a baseline compiler to compile an interpreter.
Do we implement an interpreter after having a baseline compiler?
There needs a very strong reason to do it. And in many cases, we will
not have it.
This is what happend in the Jikes RVM (Jalapeno) team, I guess.
If this is correct, discarding an interpreter was not for optimization
and rather for its implementation language.
Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
Re: [modules] classloader/jit interface
Posted by Rafal Lewczuk <ra...@gmail.com>.
> optimizing VM. On the other hand, resource constrained environments
> require VMs with as little footprint as possible. My question is: does
> it make sense to make all-in-one framework or maybe designing two
> execution engines, maybe sharing some code but having two different
> designs (object layout etc.) ? What are the upsides/downsides for
> having one versus two execution engines ?
To clarify, I mean that interpreters shine in embedded environment but
I'm not sure about full fledged server VM.
Re: [modules] classloader/jit interface
Posted by Rafal Lewczuk <ra...@gmail.com>.
Hi,
On 6/27/05, Robert Lougher <ro...@gmail.com> wrote:
> Hi Steve,
>
> First of all, I'd like to say I've found the discussions on this list
> very interesting. I don't want anybody to take my comments the wrong
> way. I'm not annoyed or offended in the slightest by people saying
> JamVM is simple or trivial -- I simply wanted to put the record
> straight. Many parts of JamVM _are_ relatively simplistic, but some
> parts I like to think are relatively advanced, following my own
> interests. These include the interpreter and the thin-locks
> implementation.
Uh, it is always easier to read, then judge someone else's code than
to design and program it oneself. I didn't think much about
sophiscation mainly because all I see in JamVM code I'm getting 'for
granted' - this is the first VM I've began dealing with. Designing and
coding quite sophiscated interpreter and ensuring it is still compact
and readable is always better than coding a horribly sophiscated beast
that no one actually understands. I was playing a bit with JamVM code
and concluded that it may be a good starting point because it is short
enough and reasonably clean (at least from my point of view). But I'm
definitely not an expert (or even fluent).
> If I have a point, is that testing should be made an integral part of
> any design decisions. Getting a VM "out there" early enables users to
> test it with a wide-range of applications. But simplistic solutions
> as in JamVM can prove problems in the future, but complex solutions
> can delay getting a VM out there, for real user testing. (For the
> record, I actually worked on JamVM for over a year before I made a
> first release).
Getting out some code early is quite important in OSS projects. Mono
folks did it extremal way, initially releasing a buch of non-working
empty stubs which sparked wider work and attracted developers. It has
some downsides too (not to say we should go the same route), but it
actually worked.
> Yes, and I think the discussions so far have been very useful. I
> personally would like to see code sooner rather than later. If not
> for the simple reason that engineers are happier reading code rather
> than design documents. Code is unambiguous.
+1
> > >JamVM are simplistic, but if code size == quality we'd all be using
> > >Microsoft Windows. It is the last trap I would have thought
> > >open-source people would fall into.
> > >
> > I think often they do, but I sure hope we're not going to go down that path.
> I really hope so as well. Maybe it's impossible for one VM to span
> the spectrum from embedded platforms to multi-processor SMP machines,
> and to scale appropriately (best commercial example is J9?).
> Pluggable components might achieve this, but pluggability adds an
> overhead in itself (unless it's compile time).
And now I'm not sure if trying to achieve all these targets in one
design actually makes sense. Things like ORP (and propably Jikes - not
sure) are intentionally omitting interpreter, relying on a fast,
non-optimizing JIT instead. I don't know but it may affect some design
decisions. Assuming that framework = set of interfaces (for example
GC) + set of conventions (for example, stack layout), discarding
interpreter part in a server VM may lead to more opportunities in
optimizing VM. On the other hand, resource constrained environments
require VMs with as little footprint as possible. My question is: does
it make sense to make all-in-one framework or maybe designing two
execution engines, maybe sharing some code but having two different
designs (object layout etc.) ? What are the upsides/downsides for
having one versus two execution engines ?
Regards,
rle
Re: [modules] classloader/jit interface
Posted by Robert Lougher <ro...@gmail.com>.
Hi Steve,
First of all, I'd like to say I've found the discussions on this list
very interesting. I don't want anybody to take my comments the wrong
way. I'm not annoyed or offended in the slightest by people saying
JamVM is simple or trivial -- I simply wanted to put the record
straight. Many parts of JamVM _are_ relatively simplistic, but some
parts I like to think are relatively advanced, following my own
interests. These include the interpreter and the thin-locks
implementation.
Writing a VM from scratch requires a wide breadth of knowledge. I
totally agree that simplistic implementations do not scale, and
retro-fitting advanced techniques can be as much work as implementing
it from scratch. But with JamVM I made the choice to implement parts
simplisticly to get a complete VM finished and released. As I'm sure
every VM implementor has experienced, after release I spent a lot of
time fixing bugs and boundary cases, and I didn't make any major
modifications for quite a few releases. And then once you have users
you're stuck in the bind that you have a relatively stable release,
which acts as a "dead-hand" on making major modifications. I've made
major modifications to the interpreter, but only after extensive
testing, and with great trepidation.
If I have a point, is that testing should be made an integral part of
any design decisions. Getting a VM "out there" early enables users to
test it with a wide-range of applications. But simplistic solutions
as in JamVM can prove problems in the future, but complex solutions
can delay getting a VM out there, for real user testing. (For the
record, I actually worked on JamVM for over a year before I made a
first release).
JikesRVM is a very complex research-oriented (and I'm not saying that
in a derogatory way) VM. I'm only giving my opinions on what it's
like implementing a VM from scratch, as a one man team. I'm extremely
impressed by JikesRVM. I wrote JamVM initially as a learning exercise
and (pleasurably) ended up with a user base. I guess JikesRVM was
initially a research vehicle, but is now intended as a wider VM. We
fit different ends of the spectrum, but I hope we can both co-exist.
After a big preamble, I've also given comments below...
On 6/26/05, Steve Blackburn <St...@anu.edu.au> wrote:
> Hi Rob,
>
> We'd obviously be shooting ourselves in the foot if we did not make the
> most of JamVM...
>
Thanks. I'm pleased that people think JamVM is a worth-while object
of study. I believe its main "claim to fame" is its small size rather
than the complexity of any technique (apart from the interpreter).
But I couldn't say in more than general terms how it achieves it,
apart from saying that I spent many years squeezing complex programs
into the ZX Spectrum using Z80 assembler (total of 48K).
> >However, I'm probably one of the few people who has written a
> >non-trivial VM from scratch, and when I started I already was an
> >experienced VM engineer. So my thoughts may be useful/interesting or
> >annoying.
> >
> >
> Useful.
>
> >First of all, just because JamVM is small does not mean it is trivial.
> > As I was interested in targetting embedded platforms, I put in a
> >large amount of design effort _from the start_ to minimise code size
> >and runtime memory usage.
> >
> The goals of harmony are broader, but this is just where we are right
> now---trying to get rolling on the up-front design effort.
>
Yes, and I think the discussions so far have been very useful. I
personally would like to see code sooner rather than later. If not
for the simple reason that engineers are happier reading code rather
than design documents. Code is unambiguous.
> > As in many other situations, smallness can
> >come from triviality or from careful design. Of course, many parts of
> >JamVM are simplistic, but if code size == quality we'd all be using
> >Microsoft Windows. It is the last trap I would have thought
> >open-source people would fall into.
> >
> I think often they do, but I sure hope we're not going to go down that path.
>
I really hope so as well. Maybe it's impossible for one VM to span
the spectrum from embedded platforms to multi-processor SMP machines,
and to scale appropriately (best commercial example is J9?).
Pluggable components might achieve this, but pluggability adds an
overhead in itself (unless it's compile time).
> >The interpreter in particular I like to think of as
> >"state-of-the-art". It is certainly not trivial, and it is more
> >optimised than most commercial VM interpreters (in many tests it is 2x
> >faster than HotSpots' interpreter under Mac OS X). This in itself has
> >taken many months of work, and I have substantially rewritten it
> >twice, so it is two iterations beyond my first interpreter, which also
> >included several advanced techniques. It now does direct-threading,
> >static and dynamic stack-caching, prefetching and makes use of
> >super-instructions.
> >
> >
> The obvious question is how Harmony can use this experience? Can we
> take JamVM in its entireity as our starting point? (I'm not in favour
> of us doing this with JamVM or any other VM) Can we take the
> interpreter as a module? Can we use the interpreter as the template for
> a new one?
>
I'm personally in favour of studying existing VMs and implementing
from scratch (not that I wouldn't agree to JamVM being used, but there
may be legal issues which I need to take off-line). I'd be happy to
discuss any design aspects of the interpreter or anything else.
> >One of the advantages of being a "one man team" is that you know the
> >code intimately. While this can lead to spaghetti-like code with many
> >inter-module dependencies if you're not careful, it can also lead to
> >compact code, as you're not afraid to re-factor modules and their
> >interfaces when the time is right.
> >
> I agree. However a VM on the scale that Harmony aspires to is well
> beyond the scope of a single person. The complexity of a production
> quality JIT is itself beyond the scope of a single person. While I
> think it is an error to overstate the difficulty of the problem, it is
> also a mistake to not realize that VMs of the scope we're aiming to
> compete against have been developed over a number of years by fairly
> large teams.
>
I also agree absolutely. How do you get the advantage of a one man
team, with a design spanning multiple people? I don't know, but
commercial teams inevitably end up with too much politics in the way,
which limits flexibility. I'm not saying open-source will be any
different, but I hope technical issues will eventually win out (we're
all engineers). This is why it's important not to set module
interfaces in stone too early.
> > Having modules written by separate
> >teams can result in in-efficiency and code duplication, as each module
> >implements its own utilities, e.g. hash tables, lists, etc., or ends
> >up marshalling arguments for an inappropriate interface.
> >
> It can, but good design is all about reducing this inefficiency. I
> don't think we can escape modularizing the JIT and the GC---they are
> just too big and too complex. Prior experience in both production and
> research VMs shows this is possible and in fact desireable. My feeling
> is that it will be essential for Harmony to leverage pre-existing JITs
> and GCs if it is going to compete. The investment in these existing
> JITs and GC is enormous. Of course this does not preclude us building
> our own over time (in fact the modularity precisely enables such an
> approach).
>
> > Trying to
> >guess every need "up front" in a neat module/interface definition is
> >doomed to failure. I believe it is better to start off with a minimal
> >interface, and then re-factor as experience dictates. Of course,
> >there are some very experienced VM implementors on this list, and
> >several module definitions already, but I like to factor through
> >experience not anticipation.
> >
> >
> I agree with you in principle. MMTk is a third generation memory
> manager---we tried to factor it as well as we could at each step, but
> only now is it really reaching the level of modularity that we had
> sought (while maintaining performance). However, I think that the
> core<->GC and core<->JIT interfaces are things that have already been
> successfully factored (with a great deal of thought and effort over many
> years). I think we need to leverage that experience in our first cut
> Harmony implementation.
>
> Harmony is not starting from scratch. It is starting from the
> experience of folks like you and many others on the list with a wealth
> of prior experience. We will not get things right first time, but I
> think we have so much experience on the table that we should make a
> decent stab at good design at the outset. Just as you said above,
> investing in good design up-front is essential.
>
I don't think we're talking at cross-purposes at all. I started off
giving reasons why JamVM was so small. Full modularisation is
important, as it allows for powerful options such as pluggability of
GC algorithms, even dynamically at runtime based on profile
information. I haven't looked at MMTk (I should). Assuming the
core<->GC and core<->JIT interfaces were adopted how soon could coding
begin? There is no interpreter in JikesRVM. Could one be easily
accommodated? I don't want to appear to be partisan, but I think
interpreters are useful in very embedded environments.
> >For the record, I believe JamVM to be fairly well "modularised", each
> >distinct component is in a separate file, with a defined interface.
> >There is very little duplicate code, and no private utility
> >implementations. The biggest problem is that as yet, I have no
> >abstraction for stack-walking. Please note, I'm not putting JamVM up
> >as an example of a module definition. I'm sure there are many, many
> >problems if you were to look at it in detail towards that end.
> >
> >
> Sure, but I think we can (and *should*) look at it for inspiration, just
> as we're looking at the other VMs, none of which are perfect in any way
> (which is why Harmony exists! :-)
>
I guess the decision has been made to use Classpath? That means most
of the discussion will revolve around VM design issues?
Thanks,
Rob.
> Cheers,
>
> --Steve
>
>
Re: [modules] classloader/jit interface
Posted by Steve Blackburn <St...@anu.edu.au>.
Hi Rob,
We'd obviously be shooting ourselves in the foot if we did not make the
most of JamVM...
>However, I'm probably one of the few people who has written a
>non-trivial VM from scratch, and when I started I already was an
>experienced VM engineer. So my thoughts may be useful/interesting or
>annoying.
>
>
Useful.
>First of all, just because JamVM is small does not mean it is trivial.
> As I was interested in targetting embedded platforms, I put in a
>large amount of design effort _from the start_ to minimise code size
>and runtime memory usage.
>
The goals of harmony are broader, but this is just where we are right
now---trying to get rolling on the up-front design effort.
> As in many other situations, smallness can
>come from triviality or from careful design. Of course, many parts of
>JamVM are simplistic, but if code size == quality we'd all be using
>Microsoft Windows. It is the last trap I would have thought
>open-source people would fall into.
>
I think often they do, but I sure hope we're not going to go down that path.
>The interpreter in particular I like to think of as
>"state-of-the-art". It is certainly not trivial, and it is more
>optimised than most commercial VM interpreters (in many tests it is 2x
>faster than HotSpots' interpreter under Mac OS X). This in itself has
>taken many months of work, and I have substantially rewritten it
>twice, so it is two iterations beyond my first interpreter, which also
>included several advanced techniques. It now does direct-threading,
>static and dynamic stack-caching, prefetching and makes use of
>super-instructions.
>
>
The obvious question is how Harmony can use this experience? Can we
take JamVM in its entireity as our starting point? (I'm not in favour
of us doing this with JamVM or any other VM) Can we take the
interpreter as a module? Can we use the interpreter as the template for
a new one?
>One of the advantages of being a "one man team" is that you know the
>code intimately. While this can lead to spaghetti-like code with many
>inter-module dependencies if you're not careful, it can also lead to
>compact code, as you're not afraid to re-factor modules and their
>interfaces when the time is right.
>
I agree. However a VM on the scale that Harmony aspires to is well
beyond the scope of a single person. The complexity of a production
quality JIT is itself beyond the scope of a single person. While I
think it is an error to overstate the difficulty of the problem, it is
also a mistake to not realize that VMs of the scope we're aiming to
compete against have been developed over a number of years by fairly
large teams.
> Having modules written by separate
>teams can result in in-efficiency and code duplication, as each module
>implements its own utilities, e.g. hash tables, lists, etc., or ends
>up marshalling arguments for an inappropriate interface.
>
It can, but good design is all about reducing this inefficiency. I
don't think we can escape modularizing the JIT and the GC---they are
just too big and too complex. Prior experience in both production and
research VMs shows this is possible and in fact desireable. My feeling
is that it will be essential for Harmony to leverage pre-existing JITs
and GCs if it is going to compete. The investment in these existing
JITs and GC is enormous. Of course this does not preclude us building
our own over time (in fact the modularity precisely enables such an
approach).
> Trying to
>guess every need "up front" in a neat module/interface definition is
>doomed to failure. I believe it is better to start off with a minimal
>interface, and then re-factor as experience dictates. Of course,
>there are some very experienced VM implementors on this list, and
>several module definitions already, but I like to factor through
>experience not anticipation.
>
>
I agree with you in principle. MMTk is a third generation memory
manager---we tried to factor it as well as we could at each step, but
only now is it really reaching the level of modularity that we had
sought (while maintaining performance). However, I think that the
core<->GC and core<->JIT interfaces are things that have already been
successfully factored (with a great deal of thought and effort over many
years). I think we need to leverage that experience in our first cut
Harmony implementation.
Harmony is not starting from scratch. It is starting from the
experience of folks like you and many others on the list with a wealth
of prior experience. We will not get things right first time, but I
think we have so much experience on the table that we should make a
decent stab at good design at the outset. Just as you said above,
investing in good design up-front is essential.
>For the record, I believe JamVM to be fairly well "modularised", each
>distinct component is in a separate file, with a defined interface.
>There is very little duplicate code, and no private utility
>implementations. The biggest problem is that as yet, I have no
>abstraction for stack-walking. Please note, I'm not putting JamVM up
>as an example of a module definition. I'm sure there are many, many
>problems if you were to look at it in detail towards that end.
>
>
Sure, but I think we can (and *should*) look at it for inspiration, just
as we're looking at the other VMs, none of which are perfect in any way
(which is why Harmony exists! :-)
Cheers,
--Steve
Re: [modules] classloader/jit interface
Posted by Robert Lougher <ro...@gmail.com>.
On 6/26/05, Rafal Lewczuk <ra...@gmail.com> wrote:
> Hi,
>
> Newbie's thoughts below.
>
> On 6/25/05, Ahmed Saad <my...@gmail.com> wrote:
> > 2. which current VM implemention would we start refining as a core for
> > Harmony? (or we would write it from scratch)
>
> Newbie's random thought: start with some simple-as-hell implementation
> (JamVM may be a good candidate) and refactor it into a modular one
> (kind of 'stretching' it onto a 'framework' set of interfaces,
> extracting GC, execution engine, class loader etc. one by one).
>
After my initial posting to this list I've gone very much back into
lurker mode. Just as I'm not into promoting JamVM, I'm not much into
defending it either (though some people may disagree with this). You
can take it or leave it.
However, I'm probably one of the few people who has written a
non-trivial VM from scratch, and when I started I already was an
experienced VM engineer. So my thoughts may be useful/interesting or
annoying.
First of all, just because JamVM is small does not mean it is trivial.
As I was interested in targetting embedded platforms, I put in a
large amount of design effort _from the start_ to minimise code size
and runtime memory usage. As in many other situations, smallness can
come from triviality or from careful design. Of course, many parts of
JamVM are simplistic, but if code size == quality we'd all be using
Microsoft Windows. It is the last trap I would have thought
open-source people would fall into. The continued assumption that
JamVM is small == simple has begun to affect my coding style, but this
is unfair to users on embedded platforms.
The interpreter in particular I like to think of as
"state-of-the-art". It is certainly not trivial, and it is more
optimised than most commercial VM interpreters (in many tests it is 2x
faster than HotSpots' interpreter under Mac OS X). This in itself has
taken many months of work, and I have substantially rewritten it
twice, so it is two iterations beyond my first interpreter, which also
included several advanced techniques. It now does direct-threading,
static and dynamic stack-caching, prefetching and makes use of
super-instructions.
One of the advantages of being a "one man team" is that you know the
code intimately. While this can lead to spaghetti-like code with many
inter-module dependencies if you're not careful, it can also lead to
compact code, as you're not afraid to re-factor modules and their
interfaces when the time is right. Having modules written by separate
teams can result in in-efficiency and code duplication, as each module
implements its own utilities, e.g. hash tables, lists, etc., or ends
up marshalling arguments for an inappropriate interface. Trying to
guess every need "up front" in a neat module/interface definition is
doomed to failure. I believe it is better to start off with a minimal
interface, and then re-factor as experience dictates. Of course,
there are some very experienced VM implementors on this list, and
several module definitions already, but I like to factor through
experience not anticipation.
For the record, I believe JamVM to be fairly well "modularised", each
distinct component is in a separate file, with a defined interface.
There is very little duplicate code, and no private utility
implementations. The biggest problem is that as yet, I have no
abstraction for stack-walking. Please note, I'm not putting JamVM up
as an example of a module definition. I'm sure there are many, many
problems if you were to look at it in detail towards that end.
Regards,
Rob.
----
Robert Lougher (Dr.)
> Upsides:
> - it should be easy for newcomers to get in;
> - while designing, there is still a working implementation, hopefully
> passing many of Mauve tests;
> - having many pieces in place at start;
> - JVM simplicity causes design work to be actually easier (than a
> bigger one) by causing refactoring less painful; (albeit harder than
> designing and implementing from scratch);
> Downsides:
> - minimal JVM usually is compact and its compactness causes code to be
> very interlinked in many places, so module extraction can be sometimes
> irritating and a bit painful;
> - dealing with legacy code causes some extra work (and bugs resulting
> in misunderstanding legacy code, but working thing along with some
> good set of tests makes it actuallly easier to squash bugs early);
> - assumptions about object/class/thread/stack/isolate structure layout
> are almost surely to be changed and may be hardwired in many places in
> the legacy code; this is the harder part of refactoring work;
> - minimal JVM design may not have some issues in mind (for example,
> JIT, class verifier etc.);
>
> Some other general comments (some are truisms, I know):
>
> - it is important to distinct between innovation/research and good
> engineering. While designing framework I'd suggest to use proven
> solutions rather than great innovations; after all, a
> reliable/production VM has to be released; well engineered framework
> shall make research easier after all; that is why I'm rather a
> C-camper and I'd suggest to make C-based framework capable to interact
> with java modules (having read some earlier posts, this is propably
> truism); make sure to make it efficient as some operations (write
> barriers, for example) are critical when it comes to performance;
> - avoid prematurely sacrificing design for the sake of performance;
> profile, locate and remove performance problems; personally, I do not
> believe the first release will be faster (or even comparable) with
> Sun's implementation (although Sun VM isn't the fastest one in the
> world); and make sure that we won't wait forever to get in par with
> Sun VM without releasing anything;
> - Java-C/C-Java (internal) interface doesn't necessarily have to be
> slow; look at GCJ and GCJX ( http://sourceforge.net/projects/gcjx )
> and JC (although JC manually loads compiled object and thus does not
> use system linker features, like effective code sharing between VM
> processes); I think it is possible to generate C-callable shared
> libraries from Java code (along with some extra segments for class
> metadata etc.); Unix ELF and Windows PE formats are pretty extensible
> and we may use a plenty of techniques here (autogenerating dedicated
> low-overhead stubs for C, having class metadata embedded in the
> library etc.); a plenty of compiling/linking/symbol tricks and
> techniques are available here;
> - there are many project we can borrow framework ideas from: ORP for
> example has some good points about GC and JIT interface; Kaffe uses
> COM-like interfaces (GC) etc.
> - having some kind of 'frankenVM' consisting of various pieces doesn't
> have to be inherently bad; did Mono emerge this way or am I wrong ?
> - someone has to build a 'big picture' and split it into parts to make
> people working on details (don't start with one or two interfaces,
> start with a big picture first: several main modules, how shall they
> interact with other modules, where are potential problems); that HAS
> to be done by a person with extensive experience in VM construction
> (engineer rather than researcher); newbies like myself fall short in
> this mainly because of not having dealt with details;
> - sorry for being a bit offensive on researchers ;) it wasn't my
> intention, I just think that we need to have a proven set of things
> first, then may do some good research on it;
>
> Regards,
> rle
>
Re: [modules] classloader/jit interface
Posted by Rafal Lewczuk <ra...@gmail.com>.
Hi,
Newbie's thoughts below.
On 6/25/05, Ahmed Saad <my...@gmail.com> wrote:
> 2. which current VM implemention would we start refining as a core for
> Harmony? (or we would write it from scratch)
Newbie's random thought: start with some simple-as-hell implementation
(JamVM may be a good candidate) and refactor it into a modular one
(kind of 'stretching' it onto a 'framework' set of interfaces,
extracting GC, execution engine, class loader etc. one by one).
Upsides:
- it should be easy for newcomers to get in;
- while designing, there is still a working implementation, hopefully
passing many of Mauve tests;
- having many pieces in place at start;
- JVM simplicity causes design work to be actually easier (than a
bigger one) by causing refactoring less painful; (albeit harder than
designing and implementing from scratch);
Downsides:
- minimal JVM usually is compact and its compactness causes code to be
very interlinked in many places, so module extraction can be sometimes
irritating and a bit painful;
- dealing with legacy code causes some extra work (and bugs resulting
in misunderstanding legacy code, but working thing along with some
good set of tests makes it actuallly easier to squash bugs early);
- assumptions about object/class/thread/stack/isolate structure layout
are almost surely to be changed and may be hardwired in many places in
the legacy code; this is the harder part of refactoring work;
- minimal JVM design may not have some issues in mind (for example,
JIT, class verifier etc.);
Some other general comments (some are truisms, I know):
- it is important to distinct between innovation/research and good
engineering. While designing framework I'd suggest to use proven
solutions rather than great innovations; after all, a
reliable/production VM has to be released; well engineered framework
shall make research easier after all; that is why I'm rather a
C-camper and I'd suggest to make C-based framework capable to interact
with java modules (having read some earlier posts, this is propably
truism); make sure to make it efficient as some operations (write
barriers, for example) are critical when it comes to performance;
- avoid prematurely sacrificing design for the sake of performance;
profile, locate and remove performance problems; personally, I do not
believe the first release will be faster (or even comparable) with
Sun's implementation (although Sun VM isn't the fastest one in the
world); and make sure that we won't wait forever to get in par with
Sun VM without releasing anything;
- Java-C/C-Java (internal) interface doesn't necessarily have to be
slow; look at GCJ and GCJX ( http://sourceforge.net/projects/gcjx )
and JC (although JC manually loads compiled object and thus does not
use system linker features, like effective code sharing between VM
processes); I think it is possible to generate C-callable shared
libraries from Java code (along with some extra segments for class
metadata etc.); Unix ELF and Windows PE formats are pretty extensible
and we may use a plenty of techniques here (autogenerating dedicated
low-overhead stubs for C, having class metadata embedded in the
library etc.); a plenty of compiling/linking/symbol tricks and
techniques are available here;
- there are many project we can borrow framework ideas from: ORP for
example has some good points about GC and JIT interface; Kaffe uses
COM-like interfaces (GC) etc.
- having some kind of 'frankenVM' consisting of various pieces doesn't
have to be inherently bad; did Mono emerge this way or am I wrong ?
- someone has to build a 'big picture' and split it into parts to make
people working on details (don't start with one or two interfaces,
start with a big picture first: several main modules, how shall they
interact with other modules, where are potential problems); that HAS
to be done by a person with extensive experience in VM construction
(engineer rather than researcher); newbies like myself fall short in
this mainly because of not having dealt with details;
- sorry for being a bit offensive on researchers ;) it wasn't my
intention, I just think that we need to have a proven set of things
first, then may do some good research on it;
Regards,
rle
Re: [modules] classloader/jit interface
Posted by Ahmed Saad <my...@gmail.com>.
On 6/25/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> So this API is really for the classes Method, Field and Class, rather
> than a bigger C API. Does this make it harder for other languages to
> use or implement? (I have to admit it's going to take a few to start
> thinking in C again...)
hmmm actually this leads back to two questions (for which there aren't
clear answers in previous threads)
1. what would be the implementation language? (or the anticipated
modular architecture would also be language-independent)
2. which current VM implemention would we start refining as a core for
Harmony? (or we would write it from scratch)
--
-ahmed
If you can give me any information about how to
study/work/live in the states or just a start
point, I'd be really grateful if you do so.
Re: [modules] classloader/jit interface
Posted by Weldon Washburn <we...@gmail.com>.
Geir,
Any update on when Apache will have a license in place so that code
can be donated to Apache Harmony project?
Thanks
Weldon
On 6/24/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> On Jun 24, 2005, at 5:17 PM, Weldon Washburn wrote:
>
> > On 6/23/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> >
> >
> >> Where is code we can start examining? What do the the java-on-java
> >> implementations do?
> >>
> >> geir
> >>
> >>
> >
> > Geir,
> > I can't talk about code just yet.
>
>
> I know, but I'm going to taunt you anyway! Taunt!
>
> Seriously, how about referring us to code in ORP at sourceforge?
>
> > But I think we can at least get
> > started on the basic, low controversy APIs. For example, the access
> > and property flags defined in the class file format are straight
> > forward boolean values. While the access/property flags may be
> > extended, it is unlikely that basic notions such as public/private
> > access would ever be removed. Below is a first stab at the API to
> > retrieve the values contained in internal classloader data structures.
> > Its understood that the JIT won't use all of the below APIs. For
> > example, some of the access properties issues are dealt with during
> > resolution and not by the jit. I used the java 1.5 version of Chapter
> > 3 of the Java Virtual Machine Spec.
> >
>
> > Comment/questions are appreciated.
> >
> > Thanks
> > Weldon
> >
> > Class access and property modifiers (table 4.1)
> > bool Class::is_public(); // ACC_PUBLIC
> > bool Class::is_final(); // ACC_FINAL
> > bool Class::is_super(); // ACC_SUPER
> > bool Class::is_interface(); // ACC_INTERFACE
> > bool Class::is_abstract(); // ACC_ABSTRACT
> > bool Class::is_synthetic(); // ACC_SYNTHETIC
> > bool Class::is_annotation(); // ACC_ANNOTATION
> > bool Class::is_enum(); // ACC_ENUM
> >
> > Field access and property flags (table 4.4)
> > bool Field::is_public(); // ACC_PUBLIC
> > bool Field::is_private(); // ACC_PRIVATE
> > bool Field::is_protected(); // ACC_PROTECTED
> > bool Field::is_static(); // ACC_STATIC
> > bool Field::is_final(); // ACC_FINAL
> > bool Field::is_volatile(); // ACC_VOLATILE
> > bool Field::is_transient(); // ACC_TRANSIENT
> > bool Field::is_synthetic(); // ACC_SYNTHETIC
> > bool Field::is_enum(); // ACC_ENUM
> >
> > Method access and property flags (table 4.5)
> > bool Method::is_public(); // ACC_PUBLIC
> > bool Method::is_private(); // ACC_PRIVATE
> > bool Method::is_protected(); // ACC_PROTECTED
> > bool Method::is_static(); // ACC_STATIC
> > bool Method::is_final(); // ACC_FINAL
> > bool Method::is_synchronized(); // ACC_SYNCHRONIZED
> > bool Method::is_bridge(); // ACC_BRIDGE
> > bool Method::is_varargs(); // ACC_VARARGS
> > bool Method::is_native(); // ACC_NATIVE
> > bool Method::is_abstract(); // ACC_ABSTRACT
> > bool Method::is_strict(); // ACC_STRICT
> > boot Method::is_synthetic(); // ACC_SYNTHETIC
> >
>
> That's pretty non-controversial :)
>
> So this API is really for the classes Method, Field and Class, rather
> than a bigger C API. Does this make it harder for other languages to
> use or implement? (I have to admit it's going to take a few to start
> thinking in C again...)
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: [modules] classloader/jit interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 24, 2005, at 5:47 PM, Rodrigo Kumpera wrote:
> If the API is meant to be language agnostic, it's just a bunch of
> constants and a function vector. This should provide enouth to build a
> better layer for each language.
>
> The API between a Java JITer and a C JVM should be coarse grained
> since cross-language calls are slow. ORP defines a very nice C++ only
> interface, but I doubt it would work well for the C++ <-> Java
> scenario.
>
> This might be too 80's, but a good interface can be well defined in
> terms of functions, structs and constants. It will work just fine for
> C/C++ and would not be that painfull or slow to use from Java (or
> whatever comes into our mind).
>
> Or we can use IDL and let it be object oriented.
How would that work?
geir
>
> Rodrigo
>
> On 6/24/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>>
>> On Jun 24, 2005, at 5:17 PM, Weldon Washburn wrote:
>>
>>
>>> On 6/23/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>>>
>>>
>>>
>>>> Where is code we can start examining? What do the the java-on-java
>>>> implementations do?
>>>>
>>>> geir
>>>>
>>>>
>>>>
>>>
>>> Geir,
>>> I can't talk about code just yet.
>>>
>>
>>
>> I know, but I'm going to taunt you anyway! Taunt!
>>
>> Seriously, how about referring us to code in ORP at sourceforge?
>>
>>
>>> But I think we can at least get
>>> started on the basic, low controversy APIs. For example, the access
>>> and property flags defined in the class file format are straight
>>> forward boolean values. While the access/property flags may be
>>> extended, it is unlikely that basic notions such as public/private
>>> access would ever be removed. Below is a first stab at the API to
>>> retrieve the values contained in internal classloader data
>>> structures.
>>> Its understood that the JIT won't use all of the below APIs. For
>>> example, some of the access properties issues are dealt with during
>>> resolution and not by the jit. I used the java 1.5 version of
>>> Chapter
>>> 3 of the Java Virtual Machine Spec.
>>>
>>>
>>
>>
>>> Comment/questions are appreciated.
>>>
>>> Thanks
>>> Weldon
>>>
>>> Class access and property modifiers (table 4.1)
>>> bool Class::is_public(); // ACC_PUBLIC
>>> bool Class::is_final(); // ACC_FINAL
>>> bool Class::is_super(); // ACC_SUPER
>>> bool Class::is_interface(); // ACC_INTERFACE
>>> bool Class::is_abstract(); // ACC_ABSTRACT
>>> bool Class::is_synthetic(); // ACC_SYNTHETIC
>>> bool Class::is_annotation(); // ACC_ANNOTATION
>>> bool Class::is_enum(); // ACC_ENUM
>>>
>>> Field access and property flags (table 4.4)
>>> bool Field::is_public(); // ACC_PUBLIC
>>> bool Field::is_private(); // ACC_PRIVATE
>>> bool Field::is_protected(); // ACC_PROTECTED
>>> bool Field::is_static(); // ACC_STATIC
>>> bool Field::is_final(); // ACC_FINAL
>>> bool Field::is_volatile(); // ACC_VOLATILE
>>> bool Field::is_transient(); // ACC_TRANSIENT
>>> bool Field::is_synthetic(); // ACC_SYNTHETIC
>>> bool Field::is_enum(); // ACC_ENUM
>>>
>>> Method access and property flags (table 4.5)
>>> bool Method::is_public(); // ACC_PUBLIC
>>> bool Method::is_private(); // ACC_PRIVATE
>>> bool Method::is_protected(); // ACC_PROTECTED
>>> bool Method::is_static(); // ACC_STATIC
>>> bool Method::is_final(); // ACC_FINAL
>>> bool Method::is_synchronized(); // ACC_SYNCHRONIZED
>>> bool Method::is_bridge(); // ACC_BRIDGE
>>> bool Method::is_varargs(); // ACC_VARARGS
>>> bool Method::is_native(); // ACC_NATIVE
>>> bool Method::is_abstract(); // ACC_ABSTRACT
>>> bool Method::is_strict(); // ACC_STRICT
>>> boot Method::is_synthetic(); // ACC_SYNTHETIC
>>>
>>>
>>
>> That's pretty non-controversial :)
>>
>> So this API is really for the classes Method, Field and Class, rather
>> than a bigger C API. Does this make it harder for other languages to
>> use or implement? (I have to admit it's going to take a few to start
>> thinking in C again...)
>>
>> geir
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [modules] classloader/jit interface
Posted by Rodrigo Kumpera <ku...@gmail.com>.
If the API is meant to be language agnostic, it's just a bunch of
constants and a function vector. This should provide enouth to build a
better layer for each language.
The API between a Java JITer and a C JVM should be coarse grained
since cross-language calls are slow. ORP defines a very nice C++ only
interface, but I doubt it would work well for the C++ <-> Java
scenario.
This might be too 80's, but a good interface can be well defined in
terms of functions, structs and constants. It will work just fine for
C/C++ and would not be that painfull or slow to use from Java (or
whatever comes into our mind).
Or we can use IDL and let it be object oriented.
Rodrigo
On 6/24/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> On Jun 24, 2005, at 5:17 PM, Weldon Washburn wrote:
>
> > On 6/23/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> >
> >
> >> Where is code we can start examining? What do the the java-on-java
> >> implementations do?
> >>
> >> geir
> >>
> >>
> >
> > Geir,
> > I can't talk about code just yet.
>
>
> I know, but I'm going to taunt you anyway! Taunt!
>
> Seriously, how about referring us to code in ORP at sourceforge?
>
> > But I think we can at least get
> > started on the basic, low controversy APIs. For example, the access
> > and property flags defined in the class file format are straight
> > forward boolean values. While the access/property flags may be
> > extended, it is unlikely that basic notions such as public/private
> > access would ever be removed. Below is a first stab at the API to
> > retrieve the values contained in internal classloader data structures.
> > Its understood that the JIT won't use all of the below APIs. For
> > example, some of the access properties issues are dealt with during
> > resolution and not by the jit. I used the java 1.5 version of Chapter
> > 3 of the Java Virtual Machine Spec.
> >
>
> > Comment/questions are appreciated.
> >
> > Thanks
> > Weldon
> >
> > Class access and property modifiers (table 4.1)
> > bool Class::is_public(); // ACC_PUBLIC
> > bool Class::is_final(); // ACC_FINAL
> > bool Class::is_super(); // ACC_SUPER
> > bool Class::is_interface(); // ACC_INTERFACE
> > bool Class::is_abstract(); // ACC_ABSTRACT
> > bool Class::is_synthetic(); // ACC_SYNTHETIC
> > bool Class::is_annotation(); // ACC_ANNOTATION
> > bool Class::is_enum(); // ACC_ENUM
> >
> > Field access and property flags (table 4.4)
> > bool Field::is_public(); // ACC_PUBLIC
> > bool Field::is_private(); // ACC_PRIVATE
> > bool Field::is_protected(); // ACC_PROTECTED
> > bool Field::is_static(); // ACC_STATIC
> > bool Field::is_final(); // ACC_FINAL
> > bool Field::is_volatile(); // ACC_VOLATILE
> > bool Field::is_transient(); // ACC_TRANSIENT
> > bool Field::is_synthetic(); // ACC_SYNTHETIC
> > bool Field::is_enum(); // ACC_ENUM
> >
> > Method access and property flags (table 4.5)
> > bool Method::is_public(); // ACC_PUBLIC
> > bool Method::is_private(); // ACC_PRIVATE
> > bool Method::is_protected(); // ACC_PROTECTED
> > bool Method::is_static(); // ACC_STATIC
> > bool Method::is_final(); // ACC_FINAL
> > bool Method::is_synchronized(); // ACC_SYNCHRONIZED
> > bool Method::is_bridge(); // ACC_BRIDGE
> > bool Method::is_varargs(); // ACC_VARARGS
> > bool Method::is_native(); // ACC_NATIVE
> > bool Method::is_abstract(); // ACC_ABSTRACT
> > bool Method::is_strict(); // ACC_STRICT
> > boot Method::is_synthetic(); // ACC_SYNTHETIC
> >
>
> That's pretty non-controversial :)
>
> So this API is really for the classes Method, Field and Class, rather
> than a bigger C API. Does this make it harder for other languages to
> use or implement? (I have to admit it's going to take a few to start
> thinking in C again...)
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: [modules] classloader/jit interface
Posted by Weldon Washburn <we...@gmail.com>.
On 6/24/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> I know, but I'm going to taunt you anyway! Taunt!
>
> Seriously, how about referring us to code in ORP at sourceforge?
You can download the last research posting of ORP from
http://sourceforge.net/projects/orp.
Two files in the bundle are particularly interesting to this email chain:
- orp-1.0.10/interface/jit_intf.h
- orp-1.0.10/common/include/Class.h
Re: [modules] classloader/jit interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 24, 2005, at 5:17 PM, Weldon Washburn wrote:
> On 6/23/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>
>> Where is code we can start examining? What do the the java-on-java
>> implementations do?
>>
>> geir
>>
>>
>
> Geir,
> I can't talk about code just yet.
I know, but I'm going to taunt you anyway! Taunt!
Seriously, how about referring us to code in ORP at sourceforge?
> But I think we can at least get
> started on the basic, low controversy APIs. For example, the access
> and property flags defined in the class file format are straight
> forward boolean values. While the access/property flags may be
> extended, it is unlikely that basic notions such as public/private
> access would ever be removed. Below is a first stab at the API to
> retrieve the values contained in internal classloader data structures.
> Its understood that the JIT won't use all of the below APIs. For
> example, some of the access properties issues are dealt with during
> resolution and not by the jit. I used the java 1.5 version of Chapter
> 3 of the Java Virtual Machine Spec.
>
> Comment/questions are appreciated.
>
> Thanks
> Weldon
>
> Class access and property modifiers (table 4.1)
> bool Class::is_public(); // ACC_PUBLIC
> bool Class::is_final(); // ACC_FINAL
> bool Class::is_super(); // ACC_SUPER
> bool Class::is_interface(); // ACC_INTERFACE
> bool Class::is_abstract(); // ACC_ABSTRACT
> bool Class::is_synthetic(); // ACC_SYNTHETIC
> bool Class::is_annotation(); // ACC_ANNOTATION
> bool Class::is_enum(); // ACC_ENUM
>
> Field access and property flags (table 4.4)
> bool Field::is_public(); // ACC_PUBLIC
> bool Field::is_private(); // ACC_PRIVATE
> bool Field::is_protected(); // ACC_PROTECTED
> bool Field::is_static(); // ACC_STATIC
> bool Field::is_final(); // ACC_FINAL
> bool Field::is_volatile(); // ACC_VOLATILE
> bool Field::is_transient(); // ACC_TRANSIENT
> bool Field::is_synthetic(); // ACC_SYNTHETIC
> bool Field::is_enum(); // ACC_ENUM
>
> Method access and property flags (table 4.5)
> bool Method::is_public(); // ACC_PUBLIC
> bool Method::is_private(); // ACC_PRIVATE
> bool Method::is_protected(); // ACC_PROTECTED
> bool Method::is_static(); // ACC_STATIC
> bool Method::is_final(); // ACC_FINAL
> bool Method::is_synchronized(); // ACC_SYNCHRONIZED
> bool Method::is_bridge(); // ACC_BRIDGE
> bool Method::is_varargs(); // ACC_VARARGS
> bool Method::is_native(); // ACC_NATIVE
> bool Method::is_abstract(); // ACC_ABSTRACT
> bool Method::is_strict(); // ACC_STRICT
> boot Method::is_synthetic(); // ACC_SYNTHETIC
>
That's pretty non-controversial :)
So this API is really for the classes Method, Field and Class, rather
than a bigger C API. Does this make it harder for other languages to
use or implement? (I have to admit it's going to take a few to start
thinking in C again...)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [modules] classloader/jit interface
Posted by Weldon Washburn <we...@gmail.com>.
On 6/23/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> Where is code we can start examining? What do the the java-on-java
> implementations do?
>
> geir
>
Geir,
I can't talk about code just yet. But I think we can at least get
started on the basic, low controversy APIs. For example, the access
and property flags defined in the class file format are straight
forward boolean values. While the access/property flags may be
extended, it is unlikely that basic notions such as public/private
access would ever be removed. Below is a first stab at the API to
retrieve the values contained in internal classloader data structures.
Its understood that the JIT won't use all of the below APIs. For
example, some of the access properties issues are dealt with during
resolution and not by the jit. I used the java 1.5 version of Chapter
3 of the Java Virtual Machine Spec.
Comment/questions are appreciated.
Thanks
Weldon
Class access and property modifiers (table 4.1)
bool Class::is_public(); // ACC_PUBLIC
bool Class::is_final(); // ACC_FINAL
bool Class::is_super(); // ACC_SUPER
bool Class::is_interface(); // ACC_INTERFACE
bool Class::is_abstract(); // ACC_ABSTRACT
bool Class::is_synthetic(); // ACC_SYNTHETIC
bool Class::is_annotation(); // ACC_ANNOTATION
bool Class::is_enum(); // ACC_ENUM
Field access and property flags (table 4.4)
bool Field::is_public(); // ACC_PUBLIC
bool Field::is_private(); // ACC_PRIVATE
bool Field::is_protected(); // ACC_PROTECTED
bool Field::is_static(); // ACC_STATIC
bool Field::is_final(); // ACC_FINAL
bool Field::is_volatile(); // ACC_VOLATILE
bool Field::is_transient(); // ACC_TRANSIENT
bool Field::is_synthetic(); // ACC_SYNTHETIC
bool Field::is_enum(); // ACC_ENUM
Method access and property flags (table 4.5)
bool Method::is_public(); // ACC_PUBLIC
bool Method::is_private(); // ACC_PRIVATE
bool Method::is_protected(); // ACC_PROTECTED
bool Method::is_static(); // ACC_STATIC
bool Method::is_final(); // ACC_FINAL
bool Method::is_synchronized(); // ACC_SYNCHRONIZED
bool Method::is_bridge(); // ACC_BRIDGE
bool Method::is_varargs(); // ACC_VARARGS
bool Method::is_native(); // ACC_NATIVE
bool Method::is_abstract(); // ACC_ABSTRACT
bool Method::is_strict(); // ACC_STRICT
boot Method::is_synthetic(); // ACC_SYNTHETIC
Re: [modules] classloader/jit interface
Posted by David P Grove <gr...@us.ibm.com>.
Jikes RVM has similar kinds of abstractions, but in Java of course ;-)
It's a pretty wide API since there are lots of things the JIT wants to
know about the program being compiled.
The javadoc for the system is online at
http://jikesrvm.sourceforge.net/api/index.html. The package of interest
is com.ibm.JikesRVM.classloader. Not all public methods of this package
are logically part of the JIT/classloader interface (the rest of the VM
also talks to the classloader of course), but a significant fraction of
them are.
--dave
Re: [modules] classloader/jit interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 22, 2005, at 12:55 PM, Weldon Washburn wrote:
> All,
>
> I'd like to start interface design discussions. Probably the simplest
> interface to start with is the API between the classloader and the
> JIT/interpreter. Another reason to start with this interface is
> because Harmony will need to be able to parse a *.class file before we
> do much of anything else.
>
> I have been looking at our current VM implementation which derives
> from a research project called ORP. Roughly, the major categories in
> the classloader/jit interface are:
>
> - register JIT callbacks (e.g., notify the jit when a given method is
> overridden)
>
> - class info (e.g., what is the superclass, which package…)
>
> - method info (e.g., exception info, get_max_stack, pointer to start
> of bytecode…)
>
> - field info
>
> - resolution (e.g., find the hard address for a static in a
> yet-to-be-loaded class)
>
> - access flags for Class, Field, Method
>
> I'd like to see harmony-dev develop detailed APIs for the above. I
> think we should be able to do this within 1-2 months.
>
> Thoughts?
Where is code we can start examining? What do the the java-on-java
implementations do?
geir
>
> -- Weldon
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org