JDK-8142368 : Copy::fill_to_memory_atomic is using Sparc BIS
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2015-11-09
  • Updated: 2019-05-28
  • Resolved: 2018-10-16
Related Reports
Relates :  
Relates :  
Relates :  
Description
The Copy::fill_to_memory_atomic function (used to implement Unsafe.setMemory) uses appropriately sized stores in for-loops to implement the described semantics, under the assumption that the appropriately aligned and sized stores will be atomic.

However, we have seen recent versions of Solaris Studio transforming similar for-loops into calls to memset, which may be implemented using Sparc block initializing store (BIS) instructions (JDK-8131330). Using BIS would violate the atomicity guarantees for these functions.

I've not checked the generated code to see if that transformation is actually happening now, but even if it's not, it is still a possibility in the future; the loop to (possibly BIS-using) memset transformation is a pretty obvious possible optimization that is safe in most situations.

And in particular, the unaligned case handled by calling Copy::fill_to_bytes is both trivially transformable to memset (except for the possibility of "out of thin air" intermediate zeros being introduced by BIS), and is currently implemented by calling memset on all supported platforms (including Sparc).

Comments
Triage: This is not on our current list of priorities. We will considered this feature if we receive additional customer requirements.
16-10-2018

I think declaring the store location volatile might be sufficient to prevent the loop transformation. The direct use of memset by Copy::fill_to_bytes requires a different solution.
09-11-2015