The GE PowerPC hotspot port found an interesting bug with compiled safepoints that conceivably effects all our ports though surprisingly as far as I know we've never seen it. Basically the problem is that when creating the thread code buffer we copy the original code into the code buffer without calling ICache::invalidate_range on it. We invalidate each of icache lines that we write an illegal instruction into but we leave the others alone. This means that if we happen to reuse malloc space for the ThreadCodeBuffer we could have old icache lines with illegal instructions in them, or even old nmethod code in them and we'd execute that instead of what's actually in the code buffer. The symptoms hey were seeing was that they'd hit an illegal instruction when trying to compiled code safepoint, come into the runtime and die while trying to verify that the instruction they stopped at was actually an illegal instruction. We can't prove that the icache contained something different than the data cache since you can''t actually look at the icache, but once they added the invalidate_range call to ThreadCodeBuffer::copy_code the problem went away. Before that it was showed up pretty reliably both on their target hardware and their ibooks running linux.
This doesn't affect 1.5 since we no longer use that compiled code safepointing mechanism.
###@###.### 2004-08-04
This doesn't affect 1.5 since we no longer use that compiled code safepointing mechanism.
###@###.### 2004-08-04