|
|
|
| Authored by: Anonymous on Friday, May 11 2012 @ 08:34 PM EDT |
Ugh.. HTML formatting ate my references to the <clinit> method. Sorry
bout that.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, May 11 2012 @ 10:43 PM EDT |
| Actually.. I'm not sure if its the Java compiler, that does this optimization.
I can't remember.. it might actually performed by the VM during class-loading
activity (maybe by the bytecode verifier, which has to do the stack simulation
stuff anyway to verify that the stack state is consistent at all control flow
join points).
FWIW, the word "dynamic" does not appear in the claims of the
'520 patent.
It is an important part of the '104 patent though -- a patent
which is about a really stupid and obvious optimization where after dynamically
resolving a symbolic reference, you overwrite the bytecode with a different one
that re-uses the same result value next time. This is an EXTREMELY OBVIOUS
memoization trick that any CompSci student capable of writing a bytecode
interpreter would probably think up the first time they noticed that resolving
symbol references was stupidly slow. The fact that Sun managed to get a patent
on this, even back in the 90's, is utterly laughable, and shows just how
hopelessly screwed up the U.S. patent system is. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, May 12 2012 @ 06:00 PM EDT |
I replaced similar code on the mainframe back in the 97. At the time it would
load a dsect that was created by an assembler routine. Since we couldn't find
any one to maintain the code and we were changing the contents on a regular
basis I moved it to a DB2 table and loaded it when the program was first run, a
small CICS routine was used to maintain the database table. When the target was
changed you just restarted the the calling program and the new targets were
loaded. [ Reply to This | Parent | # ]
|
|
|
|
|
