|
|
|
| Authored by: Anonymous on Saturday, May 12 2012 @ 05:08 PM EDT |
And is used on some hardware platforms by interrupt vectors.
Now that I think about it, I used this in a device driver for a Colour Lookup
Table back around 1981-82.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, May 12 2012 @ 08:00 PM EDT |
Its more complicated than that. The constant pool of each Java .class file,
is more like the symbol table from a traditional compiler (or the import
table of a DLL, but that stores little more than a symbol name). A
constant pool entry stores a name, type info, and other stuff. When the
symbol is resolved, that constant pool entry is overwritten with the
resolution results, and this happens at run time (while the Java VM is
interpreting an "invokevirtual" bytecode, or another bytecode that
refers to
a symbol entry in the constant pool).
Java has a bunch of support for loading new classes at run-time, so that's
why this resolving has to be done "just in time", at run-time. At
least in a
Java VM. In Dalvik, I think that the resolving is done by dexopt, and the
odex file only runs properly if you have the exact same class libraries that
it was linked against. Thats why after the Android software is patched,
dexopt has to be run again.[ Reply to This | Parent | # ]
|
|
|
|
|
