Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| JIT Help... jakmal@bpssystems.com (J. Akmal) (2001-02-23) |
| Re: JIT Help... danwang+news@cs.princeton.edu (Daniel C. Wang) (2001-02-25) |
| Re: JIT Help... torbenm@diku.dk (2001-02-25) |
| Re: JIT Help... andi@complang.tuwien.ac.at (2001-03-01) |
| Re: JIT Help... pmb@dina.kvl.dk (Peter Bertelsen) (2001-03-01) |
| Re: JIT Help... jakmal@bpssystems.com (J. Akmal) (2001-03-01) |
| Re: JIT Help... anton@mips.complang.tuwien.ac.at (2001-03-04) |
| From: | Peter Bertelsen <pmb@dina.kvl.dk> |
| Newsgroups: | comp.compilers |
| Date: | 1 Mar 2001 02:32:58 -0500 |
| Organization: | KVL |
| References: | 01-02-121 01-02-130 |
| Keywords: | Java |
| Posted-Date: | 01 Mar 2001 02:32:58 EST |
Torben AEgidius Mogensen wrote:
>
> A related problem occurs when two paths join. If they have used
> different registers to hold the stack values, the state needs to be
> made consistent. JVM (AFAIR) requires stacks to be empty at
> join-points, so this neatly solves/sidesteps the issue.
No, there is no such requirement at the JVM level: the operand stack
need not be empty at entry to a basic block. (For each bytecode
instruction the stack must always have the same depth, regardless of
the control-flow path leading to that instruction, but that's another
story.)
In Java bytecode generated by a Java compiler (from Java source) the
local operand stack is normally used only during expression evaluation,
that is, within each Java statement. However, the compiler is free to
use the local operand stack of the JVM for temporary storage across
statements and basic blocks.
--
Peter Bertelsen (http://www.dina.kvl.dk/~pmb)
PhD student, KVL, Copenhagen
Return to the
comp.compilers page.
Search the
comp.compilers archives again.