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).
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 (
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).
Attachments
Issue Links
- relates to
-
JDK-8142349 memset_with_concurrent_readers should be moved to copy.hpp
-
- Open
-
-
JDK-8142362 Lots of code duplication in Copy class
-
- Resolved
-
-
JDK-8131330 G1CollectedHeap::verify_dirty_young_list fails with assert
-
- Resolved
-