RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index (original) (raw)
Per Liden per.liden at oracle.com
Thu Apr 23 13:07:22 UTC 2015
- Previous message: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index
- Next message: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Roland,
On 2015-04-23 13:43, Roland Westrelin wrote:
Webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.0/ movptr is movq/movl, cmpptr is cmpq/cmpl and subptr is subq/subl on 32bits/64bits so you could replace:
1654 #ifdef LP64 1655 _ movq(tmp, queueindex); 1656 _ cmpq(tmp, 0); 1657 #else 1658 _ movl(tmp, queueindex); 1659 _ cmpl(tmp, 0); 1660 #endif 1661 _ jcc(Assembler::equal, runtime); 1662 #ifdef LP64 1663 _ subq(tmp, wordSize); 1664 _ movq(queueindex, tmp); 1665 #else 1666 _ subl(tmp, wordSize); 1667 _ movl(queueindex, tmp); 1668 #endif with: __ movptr(tmp, queueindex);_ __ cmpptr(tmp, 0);_ __ jcc(Assembler::equal, runtime);_ __ subptr(tmp, wordSize);_ __ movptr(queueindex, tmp);_ even if the quantities that are manipulated are not actual pointers, unless I miss something.
Thanks for looking at this!
Yes, it happens to be the same thing is this case, but bordering on being sloppy given that it's not a pointer. But if this is the preferred way then I can live with that.
Updated webrev: http://cr.openjdk.java.net/~pliden/8013171/webrev.1/
/Per
- Previous message: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index
- Next message: RFR(s): 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]