[3129] in java-interest
Comments on the Java Virtual Machine Specification
daemon@ATHENA.MIT.EDU (Antony Courtney)
Wed Nov 1 06:28:36 1995
To: java-interest@java.sun.com
From: Antony Courtney <antony@apocalypse.org>
Date: Wed, 01 Nov 1995 02:53:25 +0100
Comments on the Java Virtual Machine Specification
Antony Courtney
<antony@apocalypse.org>
The Java .class binary file format has changed between Alpha3 and the JDK
pre-Beta1 release. So far I've found that:
- the version number has changed from 0x2002d to 0x3002d
- a new, undocumented attribute type named "Exceptions" has been
added.
- the "Code" attribute associated with methods has changed size(!),
meaning that the new format is not downward compatible.
...I gave up on trying to guess the diffs when I hit the last of these.
Is an up-to-date VM specification (even in the form of "changes since Alpha3")
available?
To help you on your way towards producing an accurate VM spec. [ :-) ], here
are some comments on the Alpha3 VM specification, as it stood in the
available on-line draft of March 15, 1995:
General Bugs:
------------
Pg. 10, "iload_<n>":
The opcodes for iload_0 and iload_1 are both given as 27. (It would appear
that iload_0 should have opcode 26.)
Pg. 14, "iinc"
The opcode for this instruction is 132, but this same opcode is also assigned
to i2l on page 31. (My guess is that this is an "off-by-one" error, and that
the i2l, i2f and i2d instructions should all have their opcodes incremented
by 1, to cover opcodes 133-135 inclusive.)
Design Questions:
-----------------
Pg. 63, Sec. "Numeric Constants", subsection "Eight-Byte Constants":
All eight-byte constants take up two spots in the constant pool. If
this is the nth item in the constant pool, the next item will be
numbered n+2.
Would someone care to explain this bit of brain-damage? Since constant pool
entries are variable-length anyway, how is this useful? (The effects of
this are relatively far-reaching, since a reasonable byte-code verifier will
check that all constant indices refer to constants of a type appropriate
for the context in which they are used, and now you have a constant pool
with "holes" in the middle....)
Pgs. 34-37, Sec. "Control Transfer Instructions":
Branch instructions contain an offset to be added to the PC. From what I
can tell, these offsets are relative to the value of the PC _before_ reading
the branch instruction itself, rather than relative to the value of PC
after fetching the instruction. Why?
Omissions:
---------
- No mention is given of methods with names <init> or <clinit> and their
interpretation. (<init> is a class constructor, and <clinit> is a static
initializer, so far as I can tell.)
Little Nits and Typos:
----------------------
Pg. 4, Sec. "Constant Pool", Para 2:
The constant_info.constants_offset field contains an integer offset
(in bytes) from the start of the class to the data which describes
the constants of the class.
This sentence is obsolete; the constant pool is now at a fixed offset from
the start of the class.
Pg. 16, "multianewarray"
The instruction name printed inside the box is "anewarray", but should be
"multianewarray".
Pg. 51, Sec. "Overview":
The layout for GenericAttribute_info is correct, but ALL SUBSEQUENT ATTRIBUTE
LAYOUTS ARE WRONG. In particular, the attribute_length field is 4 bytes in
all of the attribute types.
Pg. 51, Sec. "Overview":
In the second to last paragraph, it is stated:
This length does not include the four bytes....
"four" should be changed to "six".
Pg. 52, Sec. "constant_pool_count"
It should be noted that the entries in the constant pool are of variable
size.
Pg. 52, Sec. "constant_pool", Para. 2:
[...]
constant_pool[0] is always unused. The values of constant_pool
entries 1 through constant_pool_count-1 are described by the
bytes that follow. [...]
This whole section could be more precise. First, nowhere is it stated
that constant pool entries are of variable size. Second, it does not
*explicitly* state that the bytes encoding the value of constant_pool[0] are
omitted from the class file. (Saying that the bytes are "unused" isn't
quite the same thing...) Finally, the phrase "are described by" above is
somewhat ambiguous; this could reasonably be interpreted as meaning that only
information describing the _types_ of each constant pool entry are contained
in the bytes that follow.
(I might word this section something more like this:
The constant pool is a sequence of variable-length tagged structures
encoding the values of various constants needed elsewhere in the
class file.
When constants are referenced elsewhere in the class file, the
reference is encoded as an index into the constant pool. Since entries
in the constant pool are of variable-length, it is not possible to
directly translate such constant indices into byte offsets into
the constant pool.
In certain contexts where a constant index is expected, the index
0 is used as a sentinel value. The precise interpretation of the
sentinel index will be describe by the text describing the use of
the constant index.
The constant_pool in the class file encodes the values of the constant
pool. Since constant pool index 0 is reserved as a sentinel value,
these bytes encode the values of the constants with indices 1 through
constant_pool_count-1, inclusive.
...but that's just a rough suggestion off the top of my head.)
Pg. 53, Sec. "this_class":
The definition of this_class is cyclic. What it should really state is
that this_class refers to a constant in the constant pool with tag
CONSTANT_Class which contains the index of the string name of the class.
Pg. 55, in psuedo-struct definition of "field_info":
The array length for attributes is given as "attribute_info", which should
be "attributes_info" (with the "s"). This occurs in nearly every other
psuedo-structure with attributes.
Pg. 55, Sec. "Constant Value Attribute":
The two references to "SourceFile" in the accompanying text should be changed
to "ConstantValue".
Pg. 56, last paragraph:
A field can have any number of optional attributes [...]
^^^^^
Change "field" to "method" above. (Occurs in the following sentence also.)
Pg. 60, Sec "Strings":
No value for CONSTANT_Unicode is given in the accompanying table of type,value
pais at the top.
Pg. 62, Sec "String Objects":
The heading labelled "name_index" should be labelled "string_index".
Pg. 63, Sec "Numeric Constants"
Mention should be made of the signedness of integral constants. (They are,
in fact, 2's complement signed values.)
Pg. 64, Sec. "Signatures":
The character S maps to "nsigned short" (the 'u' is missing.) What happened
to signed short?
Have Fun,
-antony
--
Antony Courtney <antony@apocalypse.org>
Berkeley, CA
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
