-
Bug
-
Resolution: Fixed
-
P4
-
hs25, 9
-
b66
-
x86
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8082742 | emb-9 | Per Liden | P4 | Resolved | Fixed | team |
While reviewing SAP changes for JDK-8012715, I decided to review the C1 barriers for G1 to see if they suffered from the same problem. An examination of the code for the G1 pre- and post- barriers showed that the sparc barriers use 64 bit accesses to read and write the _index field.
The x86_64 barriers, however, use 32 bit accesses.
Here's the code from the G1 pre barrier:
#ifdef _LP64
__ movslq(tmp, queue_index);
__ cmpq(tmp, 0);
#else
__ cmpl(queue_index, 0);
#endif
__ jcc(Assembler::equal, runtime);
#ifdef _LP64
__ subq(tmp, wordSize);
__ movl(queue_index, tmp);
__ addq(tmp, buffer);
#else
__ subl(queue_index, wordSize);
__ movl(tmp, buffer);
__ addl(tmp, queue_index);
#endif
The load of the _index value use a 64 bit load; the compare is a 64 bit compare; the subtraction is 64 bit; the back to _index, however is 32 bit.
Here's the code from the post barrier:
__ cmpl(queue_index, 0);
__ jcc(Assembler::equal, runtime);
__ subl(queue_index, wordSize);
const Register buffer_addr = rbx;
__ push(rbx);
__ movptr(buffer_addr, buffer);
#ifdef _LP64
__ movslq(rscratch1, queue_index);
__ addptr(buffer_addr, rscratch1);
#else
__ addptr(buffer_addr, queue_index);
#endif
The load/compare, subtraction, and subsequent store all use 32 bit accesses.
Fortunately this would only be a problem if x64 were a big-endian architecture. Hence the low priority.
The x86_64 barriers, however, use 32 bit accesses.
Here's the code from the G1 pre barrier:
#ifdef _LP64
__ movslq(tmp, queue_index);
__ cmpq(tmp, 0);
#else
__ cmpl(queue_index, 0);
#endif
__ jcc(Assembler::equal, runtime);
#ifdef _LP64
__ subq(tmp, wordSize);
__ movl(queue_index, tmp);
__ addq(tmp, buffer);
#else
__ subl(queue_index, wordSize);
__ movl(tmp, buffer);
__ addl(tmp, queue_index);
#endif
The load of the _index value use a 64 bit load; the compare is a 64 bit compare; the subtraction is 64 bit; the back to _index, however is 32 bit.
Here's the code from the post barrier:
__ cmpl(queue_index, 0);
__ jcc(Assembler::equal, runtime);
__ subl(queue_index, wordSize);
const Register buffer_addr = rbx;
__ push(rbx);
__ movptr(buffer_addr, buffer);
#ifdef _LP64
__ movslq(rscratch1, queue_index);
__ addptr(buffer_addr, rscratch1);
#else
__ addptr(buffer_addr, queue_index);
#endif
The load/compare, subtraction, and subsequent store all use 32 bit accesses.
Fortunately this would only be a problem if x64 were a big-endian architecture. Hence the low priority.
- backported by
-
JDK-8082742 G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index
-
- Resolved
-
- relates to
-
JDK-8012715 G1: GraphKit accesses PtrQueue::_index as int but is size_t
-
- Resolved
-