I bet NAMCO would have loved to sue them. With Google's big fat wallets they're a mouthwatering target for lawyers. They'd probably win too. Imagine the settlement theyd get for all the millions and millions of people that played it. But no, There's no way Google would have made that without permission. They're not stupid. I expect they paid NAMCO a hefty sum for the right to make that. It shows how Google is willing to spend serious cash purely to show off how awesome they are. For all the great publicity it got them, I'd say it was well worth the investment.

One reason... security. Prevents a unstable application from growing out of control, causing the whole system to start paging which with a GC becomes a diaster, dragging the whole system to a hault makign it unresponsive. So you set a heap size to "more than you'll ever need" so that it aborts if something goes wrong. There are technical advantages too. But still... I agree. The fixed heap limits are more of a pain than a benifit, especially when the default setting for the client JVM was 64MB until recently because it handnt been changed since around 1997.

To Oracle's credit, when Eclipse dev's reported the issue (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969236) Oracle immediately reverted the change within 2 days (http://hg.openjdk.java.net/hsx/hsx17/baseline/annotate/1771222afd14/make/hotspot_distro). They could have argued that it was Eclipse's fault for depending on the value in the first place and that rebranding their VM is something they should be allowed to do. But they put the best interest of other applications first. Still, it raises an issue that no one has really bothered with before. There are many Hostpot "vendor specific" options that are very commonly used. Almost every large application would configure heap sizes. There should be a standardized mechanism to define these options and thus avoid these very problems.

Im skeptical about the future of SIMD and even instruction level parallelism in general for massively parallel processors. The problem with this is that in order to get maximum utiliasation of all of the ALUs in the processor, you have to fill the entire vector with data that you can perform the SAME operation on. This means its up to the programmer or compiler to write highly vectorizable code. If you cant fill these huge 512-bit vectors, arithmetic units are going to be idle. nvidia realised this years ago, and so since the G80 their architectures have been scalar. Without vectors you can run alot more scalar threads while keeping ALL the units busy all the time. Win Win. I'll need some serious convincing if I'm to believe Intel is a real threat to nvidia in this space, especially for GPGPU.

Because as the article says, Java has a well defined and correctly implemented memory model that provides certain essential guarentees about ordering and memory consistency when dealing with high levels of concurrency. C++ does not (in its current form) have any well specified memory model, making his techniques impractical, if not impossible, since the behaviour is unpredictable. To acheive concurrent data structures in C++, the only way to do it safely, correctly and in a portable way, is to use locks. For this reason, you can expect to get much better performance in highly concurrent environments with Java with than you would get with C++.

The next version of C++ in development, is trying to provide such a memory model, based on Javas.