This would create grand effect of crippling Java as many (standalone) apps will disable it and value of Java platform will decrease rapidly. Try look to things at big picture... Luckily this won't happen, Sun won't allow this. You're perfectly OK to modify OpenJDK code if you wish, but it won't be Java.
If elimination was done per-method or per-block instead of as a global flag, I can't think why everyone would just do it by default; at the very least that would be premature optimization. Personally I would never, ever,
ever do something like that unless I had a robust mathematical proof that I would never go over the bounds limits (which you should almost always have anyways - plenty of us code C++ as well, and once I release it I'm just as positive that it's correct as I am about my Java code; I doubt many of us actually try to recover from index out of bounds errors, usually they just crash programs, so I don't know that we gain very much in a game from having the checks at all).
See below, though; I don't personally think the bounds checks are that much of a problem.
I don't know what's wrong, either you like Java strengths and use Java for them or use native languages instead.
I think that a lot of people want to use Java's strengths most of the time, but have the option to dig down and have a little more control over the details so that they can optimize bottlenecks. Think C++ vs. assembly - the fact that occasionally a critical section of C++ code is written in assembly doesn't mean that the programmer should just write the whole thing in assembly, since they still get a lot of productivity out of the higher level features even if there are a few bits that they need more explicit register control over.
(Re: bounds check elimination)
It's pretty fragile elimination that only occurs in a few relatively simple circumstances, and what's more it costs the VM time to calculate when and where it can do it.
Yeah, but those "few relatively simple circumstances" probably cover 95% of the for loops ever written, which just loop over a pre-specified and unchanging range. If your bottleneck doesn't fit into that category then it would most likely trash the cache anyways even if you did it in C++, so you've got bigger issues to contend with. And I'm pretty sure the calculation cost for those checks is all at JIT time, so it shouldn't hurt your overall performance too much.
However, I totally agree that it would be far preferable to have the option (again, only for full-privilege code) - useful as training wheels may be, nobody in their right mind welds them on to all bikes by default!
We really need to get out of this mentality that the JVM is the boss. They're our computers and we want them to do what we tell them to do not what someone at Sun decides they want them to do.
Your statement sums up my feelings almost exactly. No matter what optimizations make their way into the VM, it would be nice to have a
little more flexibility ourselves if we do turn out to need it, even if it was just in the form of a few more flags that could be used to tune full-privileged applications or some annotations on methods to be handled specially. IIRC some of the debug builds already have a lot of these options available, so it would just be a matter of swapping deployment flags so that they were included in the release VMs.
BTW Excelsior JET has had this ability for a long time now.
Does anyone here actually use JET? It seems like a great piece of technology, with a lot of stuff that I'd really love to see in the JVM proper, but the price tag is awful high, esp. for independent game devs. Also, am I correct that there's no Mac target?
If you're in need to have very performant code, write it as native code and call it using JNI. It will be just a fractional of the code base, thus it'll be much easier to check it's correctness and adding proper checks for input/outputs when interacting with Java side (again this is what JRE does when calling system calls). Then you'll get precise error reporting on most of code base and still have performant algorithm where really needed.
I'd say that was a great option if not for two things:
1) The interface is quite slow, which renders it unsuitable for drop-in replacements of small hotspots. It's really only going to help performance if you have a whole native library that you need for some heavy lifting, not just some simple bottlenecks in your own code that you want to speed up in straightforward ways like by eliminating bounds checks or manually managing memory (at least in my experience, which has been minimal because it was so painful and gained me so little).
2) It's a real pain in the ass to use.
If JNI allowed something more akin to C++ support for inline assembly, and made the interface a whole lot faster, I'd find it more usable. I know that's almost impossible to get right technically, but to me that's what keeps it from being a real solution.
