Do we really still need a 32-bit JVM?
kubrynski.com
kubrynski.com
Longer answer: Why would you assume that your development preferences (yes, preferences! not needs!) are so important as to justify cutting the legs out from underneath a huge swath of problems that other people on the planet are working on?
This isn't the only case where Java is part of the standards for various set-top boxen. Java's also commonplace as middleware on cable/satellite TV boxes, and (IIRC) some "smart TVs" use Java extensively.
ADB (to name one) would beg to differ...
That's just false. As of 2010 when I was working writing cable settop box software, cable settop boxes were legally obligated to ship with and run the JVM as part of OCAP antitrust regulation (the idea being that firmware written in Java could run on any settop box). I'm no longer in that industry, but unless something has changed in the last 5 years (which it may have) every new cable settop box shipped in the United States shipped with a JVM and booted into firmware that ran on the JVM.
As of that time, all of the platforms I worked on were 32-bit.
Before, I said, "I'm not sure where you're getting your information." Now I'm very sure you don't know what you're talking about.
It's funny that only things 64-bit ARM doesn't help with is supporting more physical RAM (32-bit designs like Cortex A7 and A15 support 1 TB) or 64-bit register width (almost totally useless). You probably want to rather use 128-bit wide NEON instructions...
For example the HP Stream 7 tablet runs Windows 8.1 32-bit edition on x86 Intel Atom Z3735G (CPU is x86-64 capable). It can only support the 32-bit JVM.
Java is intended to be right once, run anywhere. "Anywhere" will include 32 bit address spaces for the forseeable future.
See also: X32.
Could you explain how this works?
Same for any other size. Got 32 bit address space, 4GB? Well with 4 byte alignment, you shave off two bits, just multiply every pointer by 4 (left shift it by 2).
With the two highest bits, you're free to encode other information for whatever little things you need to keep track of in the runtime.
The JVM already does this on x64 so that instead of 8 byte pointers, they're only 4 bytes. But alignment bumps up the range from 4 to 16(?) GB - or something like that? Compresssed object pointers I think is the name if you wanna look up more.
Here are a few 32 bit ones for the embedded market:
As usual "All headlines that ask a question can be answered no" ( but inverted to make it more confusing ). Really the title of the article to fit the mold should be "Can we get rid of the 32-bit JVM?"
Really what should be done is take the algorithms from language competition website, and then test all of those on 32-bit versus 64-bit with different data sets. A few tests is hardly conclusive or explanative of what is fast and what is slow.
Obviously a raw call to nanotime will be slow. Do you really need nanotime? If you don't; is a lower precision call faster than nanotime?
The simulation time for the same code running the same model on a 64-bit JRE is often almost half the time required on a 32-bit JRE. With simulation times measured in hours to days, this was an extremely nice "freebie" for painlessly migrating to a 64-bit JRE.
We still support 32-bit JREs for each release as many corporate IT departments are still migrating users from 32-bit Windows environments to 64-bit. However, we strongly recommend the 64-bit version for the additional memory space that can be allocated and the reduced simulation time.
So, even 32-bit Java is good for another 292 million years or so.