please help me about understanding method "OrderAccess::acquire() and OrderAccess::acquire()"

David Holmes david.holmes at oracle.com
Wed Oct 19 22:39:54 UTC 2016


On 19/10/2016 10:35 PM, 恶灵骑士 wrote:
> src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp
> inline void OrderAccess::acquire() {
>   volatile intptr_t local_dummy;
> #ifdef AMD64
>   __asm__ volatile ("movq 0(%%rsp), %0" : "=r" (local_dummy) : : "memory");
> #else
>   __asm__ volatile ("movl 0(%%esp),%0" : "=r" (local_dummy) : : "memory");
> #endif // AMD64
> }
>
>
> inline void OrderAccess::acquire() {
>   // Avoid hitting the same cache-line from
>   // different threads.
>   volatile jint local_dummy = 0;
> }

As Kim stated these are old implementations. The intent was to produce 
some code to force a "compiler barrier" so that the acquire() semantics 
needed on x86 would exist - which is just a compiler barrier. The new 
code relies on a more direct gcc technique:

// A compiler barrier, forcing the C++ compiler to invalidate all memory 
assumptions
static inline void compiler_barrier() {
   __asm__ volatile ("" : : : "memory");
}
inline void OrderAccess::acquire()    { compiler_barrier(); }

>
> I have a few questions:
> 1,does gcc support the c++ keyword 'volatile' aquire/release sematics?
>
>
> if question 1's answer is 'yes', then i can understand the implemetation of
> method 'OrderAccess::acquire()',

Not sure exactly what you mean, but we do not rely on any C++ memory 
model operations in the hotspot code - acquire/release semanics - we 
just use volatile to flag variables that should not be optimized and use 
OrderAccess operations to explicitly enforce any memory ordering 
requirements.

>
> 2, about the part 0f ' __asm__ volatile ("movq 0(%%rsp), %0" : "=r" (local_dummy) : : "memory");'
> the 'volatile' prevents compiler optimize,
> the 'memory' ensure compiler no-reordering,

Basically yes that was the intent. The implementation has changed over time.

>
> then what about ""movq 0(%%rsp), %0" : "=r" (local_dummy) "? what's this part effect? and the local_dummywas declared as 'volatile ',is it necessary?

That was to do the actual assignment to which the volatile and memory 
would apply. This part is no longer necessary.

David

>
> thank you so so much!
>


More information about the hotspot-dev mailing list