We access caged area by doing `base + (target & mask)`. At that time, target is 64bit pointer. This is rough idea: If we can discard alignment part we can make this target address within 32bit. If the memory area is 8byte aligned, our 32bit offset can represent 32GB (4 * 8), which matches to the current gigacage area. Computation becomes like, `base + (target << alignment)`.
(In reply to Yusuke Suzuki from comment #0) > We access caged area by doing `base + (target & mask)`. > At that time, target is 64bit pointer. > > This is rough idea: If we can discard alignment part we can make this target > address within 32bit. > If the memory area is 8byte aligned, our 32bit offset can represent 32GB (4 > * 8), which matches to the current gigacage area. > Computation becomes like, `base + (target << alignment)`. Caging relies on the fact that it’s an identity operation for valid pointers. This breaks that property. I suggest not doing this.
Also, I want cage size to be tunable. We do not want to become married to a 32GB size limit.
(In reply to Filip Pizlo from comment #2) > Also, I want cage size to be tunable. We do not want to become married to a > 32GB size limit. (In reply to Filip Pizlo from comment #1) > (In reply to Yusuke Suzuki from comment #0) > > We access caged area by doing `base + (target & mask)`. > > At that time, target is 64bit pointer. > > > > This is rough idea: If we can discard alignment part we can make this target > > address within 32bit. > > If the memory area is 8byte aligned, our 32bit offset can represent 32GB (4 > > * 8), which matches to the current gigacage area. > > Computation becomes like, `base + (target << alignment)`. > > Caging relies on the fact that it’s an identity operation for valid > pointers. This breaks that property. I suggest not doing this. That sounds reasonable.