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 gok on Sunday September 18, 2016 @10:40AM (#12525480)
Well we could have just done ILP64, where all three are the same size, and that would have avoided a lot of 32 bit truncation bugs. The memory size argument never really made sense to me; there just aren't that many ints in the average program. I wonder how much of the push towards LP64 (ints are 32 bits, pointers and longs are 64) was to match Java.

I think this is one place where Swift (among other modern languages) has it right. Int is pointer sized and the other integer types are explicitly sized in their name ("Int64" not "long").

[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by pcwalton on Sunday September 18, 2016 @01:04PM (#12526057)
> I wonder how much of the push towards LP64 (ints are 32 bits, pointers and longs are 64) was to match Java.

It was to avoid breakage when porting existing programs.

> I think this is one place where Swift (among other modern languages) has it right.

We used to do ILP64 in Rust and we got a huge number of complaints; there was work by a significant segment of the community to fork the language over it. The memory usage argument is still very important to a lot of people.

[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by gok on Sunday September 18, 2016 @02:32PM (#12526472)
So there are/was sufficient amounts of existing code that assumes that int is 32 bit, but not enough that assumes long is 32 bit?
[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by pcwalton on Sunday September 18, 2016 @02:33PM (#12526479)
Right. int is much more common than long.
[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by wongarsu on Sunday September 18, 2016 @06:56PM (#12527618)
>The memory size argument never really made sense to me; there just aren't that many ints in the average program.

If you have a structure of just 5000 ints (which I imagine is fairly common), the difference between ILP64 and LP64 is the difference between your data fitting into the L1 cache and some of your data being pushed out into the L2 cache. In a thight loop that can be a big difference.

[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by danarmak on Sunday September 18, 2016 @11:29AM (#12525679)
Why are 64bit pointers needed to match Java? Why not 32bit pointers and a 64bit long? Java APIs very rarely expose pointers anyway (e.g. in NIO).
[ Parent | on HN ]
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 ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by jsnell on Sunday September 18, 2016 @12:33PM (#12525892)
That's not an option in practice, since the whole point of going 64 bit is to get larger address spaces. You could define a special purpose ABI with 32-bit pointers and 64-bit integer types (and people have done so). But doing it for the platform's standard ABI would be just commercial suicide.
[ Parent | on HN ]
Re:Vulnerabilities Induced by Migrating to 64-Bit Platforms ... by gok on Sunday September 18, 2016 @12:34PM (#12525901)
I just meant long and int being 64 and 32 respectively.
[ Parent | on HN ]