On Sun, 20 Jul 2008 08:58:02 -0700, jaycx2.3.calrobert@spamgourmet.com.remove (Robert Maas, http://tinyurl.com/uh3t) said:
| ...
| Are modern CPUs able to make aggressive assumptions about the
| cacheability of "bytecode" that is interpreted by the JVM just the
| same as they do about true machine code that is executed directly
| on the CPU? Or does the JVM methodology defeat the
| modern-CPU-assumption mechanism so that *only* the innerds of the
| JVM-interpretor itself can be aggressively cached, but tight loops
| within interpreted bytecode programs (compiled Java code) are *not*
| aggressively cached because the CPU doesn't "know" they are code,
| the CPU believes they are "just data" and hence not presumed to be
| worthy of aggressive predictions of cacheability? Or do *really*
| modern CPUs implement predictive-cacheability of both code and data
| separately, thus effectively cache both the JVM-interepretor
| (machine code) and JVM-bytecode applications ("just data")? I.e.
| are *really* modern CPUs able to recognize the design pattern of
| data that is acting as if it were instructions?

For the JVM, it seems to me that the above is a non-issue, or at
least that so far it hasn't mattered much, because the JIT compiler
turns the "data" into "real code" anyway before unleashing the CPU
on it.

---Vassil.


--
Peius melius est. ---Ricardus Gabriel.