[Mono-list] Misunderstanding the JVM stack on mono-hackers-list (was: [Mono-hackers-list] My current thinking.)

[Jay Freeman (saurik)]

If people aren't keeping up with what is happening on mono-hackers-list you
really should.  Frankly, I hate the dichotomy created by the GNOME mailing
list organizational structure, but, once again, another question entirely.
Here is a message in the archive that relates to the JVM thread:

http://mail.ximian.com/archives/public/mono-hackers-list/2001-July/000073.ht
ml

I was going to include this in my reply to the JVM performance thread, but
then decided that this should likely be seperated as it is more a reply to
listed original message.

The comments here about the "Java stack" are incorrect.  As a Java
application, you are _not_ allowed to use your stack in strange ways that
would restrict your ability to write an optimizer.  Yes, the stack exists,
and it is pretty low level, but to be valid Java byte-code you _can't_ use
it as a low-level stack.  Example: if you push a long, even though it is
really operating as two integers, you can't then pop it off twice as two
integers.  Instead, you _have_ to only use operations that work with it as a
long or use one of the conversion byte-codes.

<quote src="Java Virtual Machine Specification, Second Edition: 3.6.2">
Values from the operand stack must be operated upon in ways appropriate to
their types. It is not possible, for example, to push two int values and
subsequently treat them as a long or to push two float values and
subsequently add them with an iadd instruction. A small number of Java
virtual machine instructions (the dup instructions and swap) operate on
runtime data areas as raw values without regard to their specific types;
these instructions are defined in such a way that they cannot be used to
modify or break up individual values. These restrictions on operand stack
manipulation are enforced through class file verification (§4.9).
</quote>

Due to these restrictions you can directly map the stack system the JVM uses
(low-level stack where a single entry might take multiple slots) to the one
the CLR uses (high-level stack where each slot is the size required to store
the data type in it).  The Java Virtual Machine Specification, Second
Edition slates the various data types out into two different "categories" of
data types, Category 1 and Category 2 (for the data types that take up 1 and
2 32-bit stack slots, respectively).  At this point, even the
type-insensitive instructions (such as pop, dup, or swap) are sliced
depending on what category of data they operate on.  Example:  You _can't_
use a Category 1 pop instruction (pop) on Category 2 data (maybe a double),
instead you need a Category 2 pop instruction (pop2).

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com

----- Original Message -----
From: Miguel de Icaza miguel@ximian.com
To: <mono-hackers-list@ximian.com>
Sent: 11 Jul 2001 11:16:16 -0400
Subject: [Mono-hackers-list] My current thinking.

Hey guys,

   Here is my current thinking on some open issues:

	* The Java VM is a real stack-based virtual machine, this
	  complicates matters for the Java people.

	* The ORP JIT engine is not suitable for us.  It is suitable
          for doing `macro expansion' JITing (which is what Kaffe
          does).  This is because of the nature of the Java stack: it
          has to exist.

...

Best wishes,
Miguel.