| |||||||||||||
That way lies madnessThat way lies madnessPosted Sep 2, 2011 22:36 UTC (Fri) by martinfick (subscriber, #4455)In reply to: That way lies madness by dlang Parent article: The x32 system call ABI
> there are actually very few cases where a single application needs to address more than 4G of address space,
I guess you think java applications are few. :)
(Log in to post comments)
That way lies madness Posted Sep 2, 2011 22:47 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
yes, the number of Java applications where a single application needs to address more than 4G of memory are few.
remember that visualization is supposed to be the wave of the future, especially for things in datacenters. part of the way this works is that you slice up the memory available on a server to allocate it between many more small servers. most such servers end up with less than 4G per virtual server and what we are talking about for x32 is 4G per _application_ (not counting OS buffering, kernel allocations, or any other overhead) this is a lot more elbow room.
not every application can fit in 4G, but when you really look at it, a surprising number of them will.
and pointer-heavy things like Java are especially likely to benifit from the smaller pointers of x32
That way lies madness Posted Sep 5, 2011 7:48 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Java actually benefits so much, that Oracle JVM actually implements userspace pointer compression!
http://wikis.sun.com/display/HotSpotInternals/CompressedOops and
That way lies madness Posted Sep 5, 2011 22:38 UTC (Mon) by intgr (subscriber, #39733) [Link]
> and pointer-heavy things like Java are especially likely to benifit from
> the smaller pointers of x32
Offtopic, but interesting: 64-bit Java already offers the -XX:+UseCompressedOops option which turns on pointer compression. By dropping 3 bits from the least significant end of the address, it can address 32GB of memory using 32-bit pointer fields.
That way lies madness Posted Sep 6, 2011 14:35 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Userspace pointer compression has its own costs. In my tests it often performs worse than non-compressed version.
That way lies madness Posted Apr 2, 2012 14:30 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link]
This is quite a clever trick. If I understand rightly, what Java is doing is giving up byte-addressability, in favour of more address space. I.e. you can't create a pointer to a byte/char any more; the smallest data-type then becomes an int, and strings have to contain 4*n bytes. Given that x86 accesses memory 32-bits at a time anyway, this is a fairly natural thing to do.
That way lies madness Posted Apr 3, 2012 20:49 UTC (Tue) by ibukanov (subscriber, #3942) [Link]
> Given that x86 accesses memory 32-bits at a time anyway,
On modern CPU memory is addressed internally by cache lines that are typically 16-32-64 bytes in size. On x86 the byte access is just as fast as 32-bit access. Moreover, misaligned access to 32-bit values is allowed and is not costly as long as the variable does not cross the cache line boundary.
That way lies madness Posted May 21, 2012 15:08 UTC (Mon) by mikemol (subscriber, #83507) [Link]
For basic instructions, yes. Take a look at the SSE instructions; while there are unaligned and aligned versions for several, the aligned versions will carry better performance.
|
|||||||||||||