"Bill Leary" <
Bill_...@msn.com> writes:
>"Scott Lurndal" wrote in message news:D2Qft.292401$r%2.6...@fed13.iad...
>>"Bill Leary" <
Bill_...@msn.com> writes:
>>> ((..omitted..))
>>>> No dots. They're not the same thing. JIT is delaying code generation
>>>> until just before its execution. Self modifying code is a program
>>>> changing itself while it's running.
>>
>> A JIT will dynamically generate code that will be executed immediately.
>
>Yes.
>
>> That has the exact same effects on caches as self-modifying code.
>
>The cache is not relevant to the issue. If you're going to use this
>argument then everything, including data, is "self modifying code."
Actually, from the hardware perspective, the cache is the -only- thing
relevent.
Consider a harvard architecture with split I/D caches. Many processors
don't bother to snoop the I-cache on D-cache or DMA reads, which means
that self-modifying code causes significant consistency problems. This applies whether
its code modifying a branch address in the instruction stream or
whether hotspot is generating JIT code for some bytecode sequence that will
be executed immediately.
>
>> Take Hotspot for example: it is _exactly_ a "program changing itself
>> while it's running".
>
>No. The program was not changed while running. The executable of the
>program came into existence just before it was executed. All that's
>happened is that (1) the moment of executable generation has changed from
>some longer period before it was to be executed to immediately before
>execution and (2) if you run the program again, it does it again. It is not
>modifying itself.
Sure it is. It's altering the instruction stream of the executable to
execute dynamically generated code. And sometimes even modifying the
generated code later.
The original VMware would replace code sequences in the operating systems
it was managing (linux or windows) to run-time paravirtualize the guest
OS to avoid problematic instruction sequences (e.g. SLDT/SGDT, et. alia).
I'd consider that also to be self-modifying code.
>
>I'd assumed you were misunderstanding what JIT meant, but now I'm thinking
>you don't understand what self-modifying code is. Perhaps through never
>having encountered it?
I've written it, particularly on PDP-8 (one can do some clever things updating
operate bits in the instruction word) and on burroughs mainframes.
I consider JIT to be no different from self-modifying code from the hardware
perspective, as it is progressively and incrementally generating code to
replace hot bytecode sequences on the fly over a relatively large period of
time and executed _in the context of the generator_.
I consider any runtime generated machine code, executed by the thread/process/core
generating the code to be self-modifying
(including PLT updates in libc), which may be a broader definition than yours.