I stand corrected: at least with JVM7 the compressed references is by having part of the heap under the 4G used for a certain subset of objects that is most often pointed at. As with any partitioning, this creates opportunities for running out of memory though there is enough space on the heap.
On 5 November 2014 22:22, Rob van der Heij <[email protected]> wrote: > On 5 November 2014 16:32, John McKown <[email protected]> > wrote: > >> On Wed, Nov 5, 2014 at 8:57 AM, Steve Smith <[email protected]> wrote: >> >> > It's important to note that the reservation of x'80000000' through >> > x'FFFFFFFF' is merely to help avoid addressing issues, as well-explained >> > previously. It's not a fundamental issue at all, and the architecture >> > itself doesn't have any such restriction. >> > >> > Also, you CAN allocate memory in this area (which was extended to >> > x'7_FFFFFFFF'). There's an undocumented keyword on IARV64 called >> something >> > like USE2GTO32G. You can expect no one to help you debug storage >> overlays >> > if you decide to do that! >> > >> > I read somewhere that Java wanted this area because it could "compress" >> > pointers to 4 bytes. I presume that they only need to address to >> > doubleword granularity, and so can shift the address 3 bits to the >> right to >> > store it in a 4-byte word (and conversely shift left 3 bits to use it). >> > Addresses up to 32G are the maximum that will fit in that scheme, and >> > that's where the "restricted" area now ends. >> > >> > I don't know why Java (or anyone else) would really need to do that - >> I'd >> > think just going to 8-byte addresses would be more sensible. But there >> it >> > is. >> > >> >> Well, my _guess_ about this is that Java runs (or is supposed to run) the >> same "everywhere". Part of that "everywhere" is in the embedded space >> where >> bits remain more precious that they are on the desktop and enterprise >> class >> machines. So this address compression doesn't do much for most, but does >> in >> the embedded arena. >> >> Java already decides based on the maximum heap size whether it will need > 64-bit addresses or not. The challenge apparently is that they can have a > *lot* of pointers in their objects. So typically when you go somewhat over > the 4G of heap, you would end up having less room for your objects. Taking > advantage of the alignment you get more out of your 32-bit pointers. Even > though shifting a few bits is not hard, it does take CPU. There's > -Xnocompressedrefs to override the default for heaps between 4G and 25G or > so. > > Rob >
