I believe (please correct me if I'm wrong) that this case simply
demonstrates a bug in the Symantec code generator. A program should
never see an unconstructed (or partially constructed) object (outside
the constructors, of course). At the bytecode level, storing an
unconstructed object to memory results in a verify error. Since Java
guarantees that the result of an allocation is a zero-filled block of
memory, it would seem hard (but not impossible) to turns this into a
security problem. Moreover, at least in this case, I don't see that
writing the pointer early speeds the program up any (however,
performance prediction on x86 is a black art, at best).
Pulling machine code out of JIT compilers isn't that hard, at least
for small bits of code. It's really essential in order to understand
what's really going on. Under NT, I do the following:
o) Add an infinite loop at the point I want to disassemble.
o) Start the VC debugger
o) Start the Java program
o) From VC, attach to the running Java program (Build->Start Debug->Attach)
o) Break the running program from the debugger.
The debugger should pop up the disassembly window.
I've done similiar tricks with gdb under Linux. Presumably, those
will work with other unix-like systems.
-greg "Fair Use" thain
thain@primenet.com
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:26 EDT