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.
I think the @BoundsCheckDisabled attribute is a great idea; it could be used to mark an entire class or a single method. It would only have effect when both:
a) The code is executed with full security privilege; i.e. it’s either signed or executing locally and
b) I explicitly say that I want it turned off by the VM at startup
In other words it is no more dangerous than disabling assertions. But it could be used to great effect when writing codecs or doing some of the fancier graphical stuff, and very nicely ringfenced into particular methods or classes.
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.
BTW Excelsior JET has had this ability for a long time now.
[quote]-J-Xverify:none - this switch turns off Java bytecode verification, making classloading faster, and eliminating the need for classes to be loaded during startup solely for the purposes of verification. This switch improves startup time, and there is no reason not to use it.
[/quote]
which breaks java security just as much - that is if I understood Whitfield Diffie right.
That’s quite different thing, in how it affects typical program. You would have to manually generate bytecode to exploit it, which is not common. But what is very common, that there is chance of getting ArrayIndexOutOfBoundsExceptions in your code. Without forced bounds checking they’ll trigger crash or what is more dangerous, just overwrite some memory and corrupt state of program.
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.
Thats poor subsitude for the solution at hand: for the jni bit you can’t turn bounds bounds checking on/off adleast while debugging you reap the benefits. Also you’d only annotate a fraction of your base which you can also write the same code around. - again a crash or corrupt state (instability) still dwarfs user experience for certain applications.
[quote]Then you’ll get precise error reporting on most of code base and still have performant algorithm where really needed.
[/quote]
Under the proposed solution it’s the same.
You’re right it’s the same, but if you’re seeking for maximum performance, most likely you want also to use vectorized SSE2 code or things like that. These things are inaccessible in Java anyway and JNI way allows anything like that and it’s the proper way and very well supported.
Which gets to that it would be nice to have some SSE2 library for Java implemented as intristicts to JIT (where you wouldn’t have to worry about range checks as it would be done on full blocks). But I have problem imaginating how to make the API good enough cross platform wise.
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 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)
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!
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.
[quote]BTW Excelsior JET has had this ability for a long time now.
[/quote]
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?
I’d say that was a great option if not for two things:
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).
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.
This thread has taken a number of diversions away from its intended purpose but I can’t say that I am unsurprised to see a discussion of JNI. My feeling on Java now after having spent a week or so with the language is that it is mean-spirited. Let me explain. I was initially bemused as to why Java does not include so much of the C/C++ syntax which gives that programming language so much of its power and flexibility, but understanding dawned when I read this article: http://www.eweek.com/c/a/IT-Management/Father-of-Java-Has-His-Eye-on-Jackpot/.
I wish you the best of luck with your Java creations but I cannot help but feel that you are being led up the garden path with a watered down version of C++ by a very clever man that has deliberately forbidden vital syntactical constructs and programming idioms because the inclusion of those constructs would fight his ability to create tools that produce “semantic models of the application”, not because the use of those constructs and idioms are representative of bad programming practice. What he means by semantic models of course is a model of a program that is amenable to algebraic manipulation.
Finally, to sum up. I read comments from one young man who proclaimed that, “Java is a language that your grandfather uses.”. I’m inclined to agree; it is safe and doesn’t allow you to do anything “dangerous”. For dangerous, read “truly useful”.
I find this one of the strengths of Java, and a (huge) problem of C++. A Java parser is easier to make, its simpler and faster. It is the reason why we have so much better tools for Java than there is for C++. Stricter, simpler syntax forces the programmer to write readable code. Java is much more readable than C++. Its easier to prototype, to debug, to reuse and maintain others code. Its more productive. C++ just cant compete with Java in these fields. C++ is so much occupied with making framework code, that it takes away a lot of time from working on the useful functionality. C++ makes you invent new language constructs, it makes you improve the language itself, while Java keeps you focused on the actual task. What Java lacks is a better, more direct control over the underlying VM. The language itself is fine.
[quote=“mgianota,post:127,topic:32504”]
Just to be clear: Lisp is a powerful and flexible language, as are many of its clones and spinoffs; C++ does not even approach that, and I think you’d be hard pressed to find someone skilled in many languages that would put it on the “flexible” end of the spectrum. You can do anything you want in it, but it ain’t gonna be pretty or fun!
What C++ is is a language that allows you access to low level features, and this is the fundamental difference between it and Java. Most of the other differences are really superficial, and in most cases I actually think Java got them right (well, the lack of the friend keyword or anything that would let classes in different subpackages see each other’s internals really bugs me - that one is a real pain to work around, as in, you can’t work around it at all!).
Hmm… I have enjoyed my time on this forum immensely, it is populated by very intelligent programmers. However, the real world beckons and I have a game to produce which I would have liked to have produced in Java but cannot because of the performance. I have seen the eminently capable LWJGL library though I am unwilling to opt for using OpenGL over DirectX. It is a shame that he used OpenGL 'cos I quite liked the screenshots for Puppygames and was disappointed that I couldn’t play them. BTW IMO David Brackeen’s Pulpcore is grr-eat. And JOGL is well… JOGL reminds me of that horse that is running around outside of a closed stable door.
I still have strong reservations about using Java exclusively for writing games and I simply don’t believe it is up to the job. But I am not going to spend anymore time prodding at your hearts and minds by advocating C++ because it is obvious you have your souls set on Java. So I shall bid the forum a fond farewell and depart back to Microsoft land, where everything is bright and whizzy and explodes for no apparent reason. ;D Sanity beckons. As a parting shot, I’ll leave you with a reference to a picture of a truly great language designer: http://www.research.att.com/~bs/
I shall return when I am equipped with OpenGL… Hell, maybe I’ll write a Java SDL wrapper and return bearing a whizzy thin Java library. Who knows.
Since it seems you have your mind set on C++ anyway, why did you want to use java for your game in the first place?
I mean, to me this seems rather odd if you are unwilling to use OpenGL over DirectX. Have you considered using C#?
Just out of interest, what kind of game are we talking about anyway?
BTW, there is an SDL wrapper called sdljava. I’ve never used it, but maybe it could save you the trouble
[quote]But I am not going to spend anymore time prodding at your hearts and minds by advocating C++ because it is obvious you have your souls set on Java.
[/quote] To be honest, I think the problem is maybe that you seem to be trying to be prodding at hearts, rather than contributing compelling reasoning. Maybe it was unintended, but some of your remarks were dangerously close to trolling IMHO. (EDIT: on hindsight that was not totally fair. Sorry, just had the worst morning EVER)
Anyway, to each his own, and if you’re happy with C++ then power to you. It’s a safe bet. Believe it or not, many of us here use C++ too.
Kinda weird he couldn’t even manage to install GL drivers; although about 35% of Vista OEM machines don’t have them installed, all vendors do actually supply newer drivers that have OpenGL capability…
