Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes
mikael.gerdin at oracle.com
Fri Oct 25 08:55:10 PDT 2013
Initially I'd like to hear people's opinions on this issue. It appears to have
surfaced after we've reduced the unnecessary alignment "cushions" for
metaspace together with the fact that we are now always able to use the very
last bit of a VirtualSpace (in Metaspace).
The issue is extremely difficult to reproduce, because it relies on the exact
order and size of all metaspace allocations for a run to trigger this problem.
Description of the problem:
We recently had some mysterious crashes in the GC testing, and I narrowed them
down to the following scenario:
Imagine that we have a VirtualSpace (for Metaspace)
[ | bb]
And that the very last object allocated in such a space is a ConstMethod, and
that it has its embedded bytecodes filling up to the very end.
Consider the case when the second last bytecode (the one before "Xreturn") is
one with an embedded 2-byte index (a constant pool or local variable index)
- (bcp) checkcast #6 0xc0 0x00 0x06
- (bcp+3) areturn 0xb0
- (bcp+4) UNMAPPED MEMORY
The template interpreter here uses a 4-byte load on intel to read the index
embedded in the checkcast:
this will read the bytes [bcp+1,bcp+4] and cause a SEGV.
I looked through the code for places where we do similar loads of 2-byte
indexes and found the same problem for iload_w:
0xe73f7fbb: mov 0x2(%esi),%ebx
0xe73f7fbe: bswap %ebx
0xe73f7fc0: shr $0x10,%ebx
I looked through most places where we emit
and changed the places I could find which were affected.
Replace movl with load_[un]signed_short in the places where we load 2-byte
values from the byte code stream.
I've verified that load_unsigned_short (which boils down to movzwl, opcodes
0x0f 0xb7 only reads 2 bytes).
vm.quick.testlist -Xint on linux-i586 and x86_64(running)
More information about the hotspot-dev