otSpot VM has -Xbatch option to lighten this problem.
- Exploits more processors remaining?
- Application threads which also perform JIT compilation.
- Exploits multiple processors for JIT compilation naturally.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
compiled native code to stop thread at the
safe points, on which a stack map is provided. It's smart but prone to
causes subtle problems, an engineer working on the VM said.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
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[EMAIL PROTECTED] http://www.shudo.net/
not for optimization
and rather for its implementation language.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
;s last posting was based on direct threading technique and his saying
was correct about direct threading but my posting was incorrect in advance.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
ytecode 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 fo
fferent in performance.
- Register utilization is still important even for an interpreter.
Interpreters (1) and (4), and lightweight JIT compilers (2) and (6)
utilizes one or two machine registers to cache values around TOS.
It is also important to map VM registers (e.g. PC) onto machine registers.
This means a good interpreter cannot be implemented in a completely
portable way.
Note that I do not know how Ertl&Gregg's implementations (1) and (2)
use a machine register to keep TOS. I guess they have a little
assembly code.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
is better for us, having a portable and so-so
baseline compiler or a good interpreter which is possibly less
portable than the compiler. There will be a trade off between memory
consumption, portability and so on.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
d we may be able to have input from the developers of them if we hope.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
x.sax.de/~adlibit/
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
tion (or functions, in libgcj it turned
> out to be useful to have several). This only needs to be done once,
> at startup.
>
>
> For folks interested in pluggability, I advise downloading a copy of
> ORP and reading through it. ORP already solved these problems in a
> fairly reasonable way.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
member Kaffe and GCJ had a test suite good even for JVMs
while Mauve is targetted for class libraries.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
such a feature to
judge a method is being executed or not.
Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
13 matches
Mail list logo
