Re: [Sablevm-developer] Threading support in SableVM

[Chris P. <chr...@ma...>]

Clark VERBRUGGE wrote:

>>uniprocessor case).  If they are on separate processors, in order to 
>>meet the requirements of the JMM, each time a lock is acquired by a 
> 
> 
> I may have missed some earlier emails on this, but in case it wasn't
> mentioned already, Doug Lea's JSR-133 cookbook shows some specific
> instructions for several architectures, along with precisely where they
> need to be to ensure everything respects the (new) JMM:
> 
> 	http://gee.cs.oswego.edu/dl/jmm/cookbook.html
> 
> A simple/sub-optimal approach to see if it helps is not too hard (for
> intel, it looks like mfence before/after each load/store of a java
> volatile should do it, given the cmpxchg in monitor ops).  Inserting
> appropriate sync instructions *efficiently* would make an interested
> project by itself...
> 
> That would fix the java heap.  But are not internal sablevm operations
> more of the problem?  Are all shared data accesses (reads or writes)
> already protected by mutexes?

Hi Clark,

Replying to your mail publicly to sablevm-developer.

Thanks for the reminder about Doug Lea's cookbook.  It actually 
indicates that MFENCE is needed for unlocking a thin lock only (no C&S), 
because C&S already includes a memory barrier:

 From the IA-32 manual on LOCK:

For the P6 family processors, locked operations serialize all 
outstanding load and store operations (that is, wait for them to 
complete). This rule is also true for the Pentium 4 and Intel Xeon 
processors, with one exception: load operations that reference weakly 
ordered memory types (such as the WC memory type) may not be serialized.

I missed this earlier on.

However, I don't know if or how SableVM handles volatile Java variables. 
  Is somebody able to comment on this?

If there is no explicit treatment of volatile variables in SableVM, 
perhaps it is possible to enforce the JMM rules by inserting dummy 
method calls (using Soot) wherever an MB is needed.  If these method 
calls are synchronized, then in the absense of a VM that recognizes them 
and translates them into VM-specific MB instructions, they will still 
enforce an MB, although it will be considerably slower.

Cheers,
Chris