News for hackers. Stuff that matters.

A comment on Vulnerabilities Induced by Migrating to 64-Bit Platforms [pdf]. Parent comment

Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by hga on Sunday September 18, 2016 @12:49PM (#12525980)
While it doesn't look like it's true anymore (http://www.oracle.com/technetwork/java/hotspotfaq-138619.htm...), I sure seem to remember the Hotspot JVM having an option for 32 bit pointers for ... code, I think it was. Since few apps would need more than 4 GiB of code. And as you note, as the FAQ notes, this doesn't change much for most programming.
[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by MrBuddyCasino on Sunday September 18, 2016 @01:33PM (#12526177)
I think you mean this: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/per...
[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by hga on Sunday September 18, 2016 @01:55PM (#12526285)
Yeah, that sounds like it, and it's at the right time.
[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by hinkley on Sunday September 18, 2016 @03:06PM (#12526636)
If your heap is under 32G Java uses pointer arithmetic to fit pointers into 32 bits. "UseCompressedOops" is your google term. The reduction in cache misses offsets a lot of the overhead.
[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by jbronn on Sunday September 18, 2016 @07:34PM (#12527779)
This is also why Elasticsearch recommends using nodes with a max of 32gb RAM. [1]

[1] https://www.elastic.co/guide/en/elasticsearch/guide/current/...

[ Parent | on HN ]