Hi Dave, > From: David P Grove <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] wrote on 06/05/2005 10:48:29 PM: > > > - The machine code concatinating technique consumes much memory. > > In my experience, generated machine code is about 10 times larger > > than the original instructions in Java bytecode. > > > > In the paper, the authors have not mentioned memory consumption of the > > technique. We cannot guess how much it is precisely, but it is > > possible to be a big drawback. Yes, we can say the same for the > > approach taking a baseline compiler instead of an interpreter (like > > Jikes RVM). Memory consumption of the baseline compiler of Jike RVM > > is very interesting. > > It's platform dependent of course, but on IA32 isn't too horrible. For > example, running SPECjvm98 we see a 6.23x expansion from the Jikes RVM > baseline compiler machine code bytes over bytecode bytes. Thanks for giving us such an useful number. It looks reasonable. > One thing to > note is that a threaded interpreter would see something like a 2-4x > expansion over "normal" bytecodes when it converts from bytecodes to its > internal form (arrays of function pointers). Direct threading interpreters like JDK's one work on plain Java bytecode and they do not need to expand normal bytecode instructions. Such expansion may have been required if Java bytecode is not linear and rather a tree or other complicated form. Then, > So, a 6x expansion is > probably only roughly 2x worse than some interpreted systems would > actually see in practice. We have to just say the baseline compiler of Jikes RVM generates 6x larger native code than the original bytecode instructions. 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? Kazuyuki Shudo [EMAIL PROTECTED] http://www.shudo.net/
