Do we really still need a 32-bit JVM?(kubrynski.com)
kubrynski.com
Do we really still need a 32-bit JVM?
http://www.kubrynski.com/2015/05/do-we-really-still-need-32-bit-jvm.html
9 comments
As long as there are 32-bit processors or 32-bit hardware accelerated VMs then: Yes.
Not only that, as usual there is the fallacy that there is only one JVM.
Here are a few 32 bit ones for the embedded market:
http://www.is2t.com/products/
https://www.aicas.com/cms/en/JamaicaVM
http://www.atego.com/products/atego-perc-pico/
Here are a few 32 bit ones for the embedded market:
http://www.is2t.com/products/
https://www.aicas.com/cms/en/JamaicaVM
http://www.atego.com/products/atego-perc-pico/
Well, 32 bit might get relegated to microcontrollers soon, and other specialist stuff that doesnt run the JVM much. I cant see much mainstream 32 bit hardware being made in even 5 years.
That seems like a pretty radical claim, considering that something like 99.9% of extant Android phones are 32 bit.
This. Even _new_ ARM processors like A9 and A15 are still 32-bit, and this is at the heart of many (most?) smartphones. Many low end x86 processors like a lot of Atom chips are also 32-bit only. Just because most new consumer x86 is now 64-bit doesn't mean at all that it's time to sunset a 32-bit JVM (if you'll ever be able to do that).
Oh, it'll shift to 64-bit on ARM soon enough. Power efficiency. Flags register consumes less power and less memory (cache) subsystem traffic.
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...
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...
Gingerbread is roughly four and a half years old and it still runs on about 6 percent of Android devices in use. Adoption of new technology lags a lot more at the tail - if Android was going to be completely off 32-bit in five years time it would have to have significant adoption already.!
[deleted]
I think for that case is fair to say that system on chip ~= microcontroller (even when we know that they are not http://stackoverflow.com/questions/6531423/microcontroller-v...)
I'm not sure where you're getting your information here. One very pervasive area I don't see going 64-bit any time soon is cable settop boxes.
They dont tend to run the jvm. But they will quite likely end up running 64 bit as speeds increase and they get upgraded. Both mips and arm are pushing 64 bit quite a bit now, these type of applications dont really need 64 bit but it wont cost anything different.
Actually, quite a few set-top boxes do run Java and thus some form of a JVM (though perhaps not HotSpot). Of particular note, Java (specifically, BD-J) is a mandatory part of the Blu-Ray standard in order to implement things like interactive menus, disc updates (for post-release subtitle updates, for example), etc., so literally every device with Blu-Ray playback capability runs a JVM (probably HotSpot). I'd reckon most of these run 32-bit processors, and probably will for the next several years.
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.
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.
Actually, Java was originally designed for interactive television (http://www.oracle.com/technetwork/java/javase/overview/javah...).
> They dont tend to run the jvm.
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.
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.
They dont tend to run the jvm.
ADB (to name one) would beg to differ...
ADB (to name one) would beg to differ...
Even today there are some minority 32-bit products around in the PC world where the Oracle Java VM can run.
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.
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.
It doesn't run Oracle's JVM, but there are plenty of other ones to choose from.
This is the only answer.
Java is intended to be right once, run anywhere. "Anywhere" will include 32 bit address spaces for the forseeable future.
Java is intended to be right once, run anywhere. "Anywhere" will include 32 bit address spaces for the forseeable future.
That is a lovely typo.
It was so good my brain corrected it several times before spotting it :D
Too late to edit, I'm committed!
64 bit JVM can target 32-bit address space just fine. In fact if you know you're doing that, then with 4 byte alignment, you only need 30 bits for a pointer, leaving 2 for other optimizations. Maybe.
See also: X32.
See also: X32.
> In fact if you know you're doing that, then with 4 byte alignment, you only need 30 bits for a pointer, leaving 2 for other optimizations.
Could you explain how this works?
Could you explain how this works?
Sure. Suppose you have an 8 byte address space. You'll need 3 bits to address them (0,1,..6,7). But, if the only objects you store must fall on a 4 byte boundary, there's only two valid addresses: 0 and 4. You can represent that with one bit, just multiply the value by 4 (0->0, 1->4).
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.
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.
So meaning, oh yes please drop support for 32bit, please!!!!
Garbage collection is much faster on 32 bit JVM than a corresponding 64 bit JVM. Therefore I prefer to my small web applications or component that don't need a ton of heapspace on 32 bit JVM.
Can't you tune a 64-bit JVM to have a smaller heap or GC as aggressively as a 32-bit JVM?
Citation needed. Is this true even with compressed pointers?
Um, the article explicitly tested that case. Does that count as a citation?
Well now that you mention it. How I overlooked that is beyond me. Still hard to believe the results, what is going on there?
Article more or less: "I don't think that we do, so I tested it a bit. Tests confirm my assumptions. Still; there are cases where 32 bit is faster. I won't bother to explain why."
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?
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?
So going to 32-bit JVM you sometimes get a slight performance boost, sometimes a slight performance loss, and overall not a huge difference, so I don't think it's really worth it, or even worth trying.
The performance difference for 32-bit vs 64-bit JVMs can be significant for some workloads. I develop a desktop engineering simulation application in Java.
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.
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.
How is time handled on a 32-bit JVM?
Java has always stored time values as 64-bit longs representing milliseconds since the Unix epoch. This includes System.currentTimeMillis(), as well as what the java.util.Date class uses internally. I'm assuming that the Java 8 date-time API also does this (or something better—either way, I'm certain that it's y2038-compliant).
So, even 32-bit Java is good for another 292 million years or so.
So, even 32-bit Java is good for another 292 million years or so.
32-bit is with respect to addressable memory. All JVMs still have 64 bit longs and doubles, etc.
Maybe you don't, but we most definitely do.
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?