Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2215451 | 8 | Vladimir Kozlov | P4 | Resolved | Fixed | b08 |
JDK-2214859 | 7u2 | Vladimir Kozlov | P4 | Closed | Fixed | b08 |
Hi Vladimir,
For user-level programs such as JVM/GC, there are only two Block Initializing Store ASIs that are of real interest, most other variants are for privileged and hyper-privileged usage:
ASI_ST_BLKINIT_PRIMARY (ASI_STBI_P), ASI Value 0xE2
ASI_ST_BLKINIT_MRU_PRIMARY (ASI_STBIMRU_P), ASI Value 0xF2
Most-Recently-Used (MRU) variant of this special store controls $L2 replacement policy, and is a result of our SPARC-Java VT collaboration that we started in 2007; citing Mark Luttrell from one of our earlier discussions on this topic:
"My understanding is that in the L2, past projects always reset the used bit (or similar state) of a line touched by a block-initializing store. This caused it to be preferred for eviction, and helped to keep a copy operation from wiping out a large portion of the cache data. Early on in VT, the Java group was looking at using block-init store for stuff besides copying (object allocation and initialization I believe), but the behavior of making the line preferred for eviction was undesirable there. (If you're initializing an object you're probably going to use it soon.) So, we added the MRU variants which install the line as *most* recently used - the same behavior as a typical cache access."
Please sync with Mark Luttrell about current status of this implementation and memory ordering issues that John described below. As Mark explained earlier today, we expect to see performance gains over traditional Block Load/Store variants, so all this is good news for performance!
Best regards,
-- Zoran Radovic
For user-level programs such as JVM/GC, there are only two Block Initializing Store ASIs that are of real interest, most other variants are for privileged and hyper-privileged usage:
ASI_ST_BLKINIT_PRIMARY (ASI_STBI_P), ASI Value 0xE2
ASI_ST_BLKINIT_MRU_PRIMARY (ASI_STBIMRU_P), ASI Value 0xF2
Most-Recently-Used (MRU) variant of this special store controls $L2 replacement policy, and is a result of our SPARC-Java VT collaboration that we started in 2007; citing Mark Luttrell from one of our earlier discussions on this topic:
"My understanding is that in the L2, past projects always reset the used bit (or similar state) of a line touched by a block-initializing store. This caused it to be preferred for eviction, and helped to keep a copy operation from wiping out a large portion of the cache data. Early on in VT, the Java group was looking at using block-init store for stuff besides copying (object allocation and initialization I believe), but the behavior of making the line preferred for eviction was undesirable there. (If you're initializing an object you're probably going to use it soon.) So, we added the MRU variants which install the line as *most* recently used - the same behavior as a typical cache access."
Please sync with Mark Luttrell about current status of this implementation and memory ordering issues that John described below. As Mark explained earlier today, we expect to see performance gains over traditional Block Load/Store variants, so all this is good news for performance!
Best regards,
-- Zoran Radovic
- backported by
-
JDK-2215451 Use BIS for zeroing on T4
- Resolved
-
JDK-2214859 Use BIS for zeroing on T4
- Closed
- duplicates
-
JDK-6512957 heap allocator should use block-init store on N2
- Closed