backedge checks

[Andrew Haley]

Edward Nevill wrote:
>> I knew this wasn't right, and I just realized why.  Every processor has its own
>> data cache, and these caches may not be coherent.  You could potentially wait
>> for ever before a processor would read the changed dispatch table.
>>
>> I think this could probably be solved by sending a signal to every thread that
>> is supposed to move to a safepoint.  If there's any additional processing needed
>> the signal handler can do it.
>>
>> Also, the thread updating the table would have to flush its own caches/write buffers/etc.
>>
>> Finally, unless the table itself is marked as volatile there's no guarantee that
>> it would be written before the flush.
> 
> If you seriously think any of this code is MP safe at the thread level
> then I suspect you have been doing some recreational pharmaceuticals:-)
> 
> Think about is, any update to the thread list needs to be MP safe.
> Even the setting of the _state variable needs to me MP safe and its isn't
> it just does
> 
> 	_state = _synchronizing;

It wouldn't work if that were all it did: there are memory barriers there
too.

But anyway, it looks like the template interpreter's notice_safepoints()
does simply:

static inline void copy_table(address* from, address* to, int size) {
  // Copy non-overlapping tables. The copy has to occur word wise for MT safety.
  while (size-- > 0) *to++ = *from++;
}

void TemplateInterpreter::notice_safepoints() {
  if (!_notice_safepoints) {
    // switch to safepoint dispatch table
    _notice_safepoints = true;
    copy_table((address*)&_safept_table, (address*)&_active_table, sizeof(_active_table) / sizeof(address));
  }
}

so I can't see any reason  for the C++ interpreter not to do the same.

I do wonder how this works in general, though.  It does seem like the code
assumes memory semantics stronger than those guaranteed by POSIX threads.
Maybe the template interpreter in hotspot isn't used on boxes with weakly
consistent caches? That seems unlikely, though.  I'll ask.

> Exactly the same problems apply to this, it may not be updated in the cache
> of another processor.
> 
> Even the kernels user level atomic compare and swap is not MP safe (it may
> be MP safe on some implementations but it is not guaranteed so), and you
> are going to have a hard job making your program MP safe if your atomic
> operations are not MP safe.

The atomic operations are MP safe by definition.

Andrew.