On 12/10/2010 7:22 AM, Tom Marchant wrote:
I defer to Peter's knowledge of the original intent, since the bar is a z/OS construct and not a hardware one. For my purposes, data "above the bar" is data that requires me to be in 64-bit mode. It makes little difference whether that means above 2 GB or above 4 GB, since I will never allocate storage within that range. However, if I need to examine Java stack in that range, the distinction becomes blurred.
Either way you'll need to be in 64-bit addressing mode since there is no 32-bit addressing mode. That's where I draw the line. 24-bit, 31-bit, 64-bit. Who cares where the system actually allocates the virtual addresses? Actually, it does matter for performance minded folks. Java got a substantial performance boost by using so-called "compressed" pointers which is really just a fancy way of saying that they stored addresses in four bytes instead of eight to minimize memory and cache line usage. After seeing that, we tried something similar in some performance-sensitive 64-bit code. We didn't want to code USE2GTO32G because it wasn't supported on all of the back z/OS releases we needed to support. So, instead we changed from using pure 64-bit addresses to using 32-bit offsets within the 64-bit memory object. Incredibly, we saw some measurable performance improvement even though we *added* AGF instructions to the code path (carefully so as to avoid AGI as much as possible). -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 [email protected] http://www.phoenixsoftware.com/
