- 
    Bug 
- 
    Resolution: Fixed
- 
     P4 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
 
-