The HotSpot code base uses memset and memcpy in places where the C standard allows it to do so safely. But these functions are not safe for concurrent use, which means there is a long-term bug tail that arises from using them on concurrently visible data structures.
For this reason, HotSpot has a utility, copy.hpp, which defines more predictable versions of memset and memcpy. This utility also has a portability framework which allows CPU-specific implementations as needed, for best performance.
Maintaining this subtle kind of code requires a centralized point for managing such library functions, which in HotSpot is copy.hpp.
For these reasons, the function memset_with_concurrent_readers_sparc needs to be moved out of its own little niche and into copy.hpp.
Any similar specialized methods need similar centralization. I don't know of any other cases besides memset_with_concurrent_readers_sparc.
For this reason, HotSpot has a utility, copy.hpp, which defines more predictable versions of memset and memcpy. This utility also has a portability framework which allows CPU-specific implementations as needed, for best performance.
Maintaining this subtle kind of code requires a centralized point for managing such library functions, which in HotSpot is copy.hpp.
For these reasons, the function memset_with_concurrent_readers_sparc needs to be moved out of its own little niche and into copy.hpp.
Any similar specialized methods need similar centralization. I don't know of any other cases besides memset_with_concurrent_readers_sparc.
- duplicates
-
JDK-8142349 memset_with_concurrent_readers should be moved to copy.hpp
- Open
- relates to
-
JDK-8131330 G1CollectedHeap::verify_dirty_young_list fails with assert
- Resolved