JDK-4679944 : memory barrier instructions emitted for "volatile" keyword way too heavy on IA32
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: x86
  • Submitted: 2002-05-05
  • Updated: 2016-04-19
  • Resolved: 2016-04-19
Related Reports
Duplicate :  
JDK-4904703 - Need support for JSR-166 in VM
Description
On Sparc you apparently emit the appropriate memory barrier or "fence"
instructions to prevent the processor from reordering load and store
operations.  On IA32, however, I think your memory barriers are way too
heavy.  You can get away with much cheaper memory barriers.  You are
basically making the volatile keyword a _very_ expensive construct with
Hotspot (it is still pretty expensive but it shouldn't be that expensive).

Give me a week or two and I can send you a micro-benchmark where I think I can
explain what I mean.
Comments
Fixed as part of JSR-166 implementation: if( LP64_ONLY(true ||) VM_Version::supports_sse2() ) { emit_byte( 0x0F ); // MFENCE; faster blows no regs emit_byte( 0xAE ); emit_byte( 0xF0 ); } else { // All usable chips support "locked" instructions which suffice // as barriers, and are much faster than the alternative of // using cpuid instruction. We use here a locked add [esp],0. // This is conveniently otherwise a no-op except for blowing // flags (which we save and restore.) pushf(); // Save eflags register lock(); addl(Address(rsp, 0), 0);// Assert the lock# signal here popf(); // Restore eflags register }
19-04-2016
EVALUATION Need to liten up on ia32 mem barriers ###@###.### 2002-05-07 Reports from Doug Lea & David Dice suggest we should use locked add [sp],0 which will only blow flags and is much lighter weight than CPUID. ###@###.### 2002-10-30
07-05-2002