Shark: fix ldc(Class)

[Andrew Haley]

Gary Benson wrote:
> Andrew Haley wrote:
>> Gary Benson wrote:
>>> Andrew Haley wrote:
>>>> I've been trying to track down a mysterious bug in Shark for
>>>> a couple of weeks, and I finally got it.  It turns out that
>>>> there's no code generated for ldc(Class).  What fun!
>>>>
>>>> Oh well, I learned a lot...  :-)
>>> Was it not hitting an Unimplemented() or similar?
>> It simply generated a read from the constant pool.  The cpool entry
>> points to a classOopDesc, so code has to be generated to get from
>> the classOopDesc to the Class.
> 
> Yuk :(
> 
>> Incidentally, I think there has to me a memory barrier between
>> reading the tag and reading the constant pool entry.  The c++
>> interpeter does this by calling byte_at_acquire().
> 
> A lot of those OrderAccess functions are barrierless on every platform:
> 
>  hotspot/src/share/vm/oops/constantPoolOop.hpp: constantTag tag_at(int which) const { return (constantTag) tags()->byte_at_acquire(which); }
>   ...
>  hotspot/src/share/vm/oops/typeArrayOop.hpp: jbyte byte_at_acquire(int which) const { return OrderAccess::load_acquire(byte_at_addr(which)); }
>   ...
>  hotspot/src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
>  hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:         inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
>  hotspot/src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp: inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
>  hotspot/src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
>  hotspot/src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
> 
> I just did the same for Zero.  It seemed hacky, but I wasn't sure what
> else to do...

Many of the CPUs we use won't be affected.  SPARC apparently can use
either Total Store ordering (TSO) or Partial Store Order (PSO) or
Relaxed Memory Order (RMO).  :-)

http://developers.sun.com/solaris/articles/atomic_sparc/

>From what you say, I think the Java VM assumes TSO.

TSO is, approximately, what we have on x86_64 too.

PowerPC uses, as far as I can see, Relaxed Store Ordering.
So, Load Acquire requires a sync.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html
shows the PPC Code Sequences needed for each operation.  Example 3,
Store/Load, shows what's needed for reading and updating constant
pool entries:

#  Thread 0:

	x.store(1, memory_order_relaxed);
	y.store(1, memory_order_release);
	

# Thread 1:

	r1 = y.load(memory_order_acquire);
	if (r1 == 1)
		r2 = x.load(memory_order_relaxed);

(x is the value, y the tag.)

Andrew.

see also http://www.cs.utah.edu/mpv/papers/neiger/fmcad2001.pdf