| The more I search around, the more I stumble on evidence that the symbol
resolution in Java VMs has nothing to do with the bytecode instructions.
;)
Here's an excerpt from Chapter 5 of the book
"Inside the Java Virtual Machine", by Bill Venners.
The
Constant Pool
For each type it loads, a Java virtual machine must store a
constant pool. A constant pool is an ordered set of constants used by the type,
including literals (string, integer, and floating point constants) and symbolic
references to types, fields, and methods. Entries in the constant pool are
referenced by index, much like the elements of an array. Because it holds
symbolic references to all types, fields, and methods used by a type, the
constant pool plays a central role in the dynamic linking of Java programs. The
constant pool is described in more detail later in this chapter and in Chapter
6, "The Java Class File."
And here's my very favorite part of this
chapter:
The Java virtual machine then replaces the symbolic
reference in Volcano's constant pool entry one, which is just the string
"Lava", with a pointer to the class data for Lava. If the virtual machine ever
has to use Volcano's constant pool entry one again, it won't have to go
through the relatively slow process of searching through the method area for
class Lava given only a symbolic reference, the string "Lava". It can just use
the pointer to more quickly access the class data for Lava. This process of
replacing symbolic references with direct references (in this case, a native
pointer) is called constant pool resolution. The symbolic reference is
resolved into a direct reference by searching through the method area until the
referenced entity is found, loading new classes if necessary.
(emphasis mine)
So its the constant pool entry where the
symbol is stored, and the constant pool entry that gets resolved, and the
process of doing this is called "constant pool resolution".
The bytecode
instruction has literally nothingto do with this process, except for
triggering it in the first place (when executing the bytecode, it needs the
constant pool entry to be a resolved reference. If it hasn't been resolved yet,
the VM stops and does the "constant pool resolution" process on it, and
afterwards, it goes back and resumes executing the bytecode.)
Case closed!
Hopefully nobody will ever be found to infringe the worthless '104 patent again,
since the "invention" it covers has never been concretely realized in a Java VM
or any other VM that I've heard of. [ Reply to This | Parent | # ]
|
