OS made in Java
- Thread starter K.I.L.E.R
- Start date
Sounds interesting I guess, but in my experience(as a user, and a somewhat as a programmer) java has very high overhead. I don't know if I'd want a bloated operating system, even if it is 100% secure, unless there is some new x86 cpu coming out that operates on byte code without a software layer to convert it.
In my experience I beg to differ (about Java having very high overhead).
You seen the commercial Java+XML MMORPG?
It's in Chinese, but no one seems to complain that it's slow.
http://www.javagaming.org/cgi-bin/J...d=Announcements;action=display;num=1071648278
You seen the commercial Java+XML MMORPG?
It's in Chinese, but no one seems to complain that it's slow.
http://www.javagaming.org/cgi-bin/J...d=Announcements;action=display;num=1071648278
Your experience would change if you knew the internals of a java virtual machine.K.I.L.E.R said:
You can write game engines in Java, because computers are so damn fast and the game engine part doesn't need to be particularly fast or efficient.
arjan de lumens
Veteran
Some processors (most x86 except P4) depend on certain memory alignment of instructions, limited numbers of RETs/JMPs/whatever in each memory block (16 or 32 bytes), that sort of stuff. ASM hides instruction alignment issues behind an abstraction layer, reducing performance.Tokelil said:
Pretty much the only example I could come up with, though.
Would you not still need to follow such rules of memory alignment etc. when writing machine code? I would have thought that an abstraction layer on ASM level would only be there to help the programmer, not making the code slower after it is compiled. (I don’t know much about ASM on new systems, since I have only programmed ASM on a 186.)
True true... But at least the program wouldn’t be slow because of high overhead from JIT compiling and memory management.
The only way to program a large project in assembly is to use a lot of canned code and programming by rote because its tedious to optimize all of that all the time while paying attention to pipeline bubbles, etc. (Like saving off all registers when entering a subroutine, or using the macro language to make a psuedo high level language) If you're programming in a higher level language, the compiler doesn't mind tedious, so you end up with _overall_ tighter code.
Of course, given any routine, I can likely beat the compiler. I just can't do it consistantly.
Of course, given any routine, I can likely beat the compiler. I just can't do it consistantly.
StealthHawk
Regular
Fox5 said:
Why don't you just compile the Java source for the OS directly into machine code, then it won't have the high overhead.
Java still has higher overhead than C/C++ beacuse it can't put objects on the stack (has to be in the heap, IIRC), so it's highly dependent on automatic garbage collection. Other things like forced dynamic type checking and dynamic binding also make higher overhead.
StealthHawk
Regular
Yeah, Java does have higher overhead than C++, but I'm not sure how significant it if you compile the source directly to machine code. Basically, I am admitting that the overhead would still be higher, but I'm really wondering how much overhead that would be. I don't think it would be as bad as some people imagine.
AFAIK, you don't have to rely on automatic garbage collection, you can explicitly call it.
I'm 99% sure you're right that objects in Java are stored on the heap.
AFAIK, you don't have to rely on automatic garbage collection, you can explicitly call it.
I'm 99% sure you're right that objects in Java are stored on the heap.
pcchen said:
This is both incorrect and spouts a common myth about garbage collector performance. First, Java runtimes can perform escape analysis on objects and allocate some of them on the stack. There are a couple non-Sun VMs that do this. Secondly, heap allocation overhead in modern VMs is on the order of stack allocation. It consists of incrementing a pointer and returning the old one. You pay almost nothing upfront for heap allocation, you pay amortized over time for collection.
The collector gradually promotes objects that live longer from a young "stack-like" generation to an older longer-lived more "malloc()-like" generation. It then runs different algorithms on the differing heaps. The "stack"-like heap, with it's high-churn/short-lifespan-objects gets a parallel multithreaded copying-collector. The older long-lived objects in the old generation get a concurrent mark-sweep collection.
Proper tuning of the size and promotion rules for the GC heaps via a builtin-profiler can reduce the "overhead" of GC to very small levels.
None of these are forced. Dynamic binding in Java is not "forced". Not only can the JVM eliminate dynamic dispatch, it can INLINE functions across dynamic boundaries, something C++ doesn't normally do, because modern JVMs use profile based optimizations at runtime.
Just like C++, much of the time, the compiler can prove a particular virtual method gets dispatched, and remove the virtualized dispatch. The programmer can also unvirtualize a method via "final". Unlike C++, Java VMs keep detailed profile statistics about runtime method invocations, types, and class hierarchy. Using Class Hierarchy Analysis, the VM can further eliminate the possibility of a polymorphic dispatch. After CHA, using profile data, the VM can speculatively compile an inlined version of a polymorphic dispatch and do type-inferencing.
Furthermore, with respect to automatic loop bounds checking, in the majority of cases, these are eliminated. Typical examples like iterating over a collection and iterating through an array are easily removed.
If the compiler cannot be assured it can eliminate a bounds check, it does unrolling via loop splitting. It splits a loop into an initialization prolog phase, an invariant part in which bounds check is unneccessary, and an epilogue which bounds check needs to occur.
In no way does a loop in Java like
for(int i=0; i<n; i++) { a ... }
generate code that loops like this
for(int i=0; i<n; i++) { if(i < a.length) { a ... safe, check passed } }
If your application is non-interactive, GC pauses won't hurt you, and you will run with similar if not better performance than C++ (if lots of polymorphism is used). If you application is interactive, GC pauses may or may not be an issue, and tuning will be a big issue.
I'm not advocating Java for games, but there is a lot of nonsense about Java performance still going around. I've personally written code that trounced C++ code if object oriented features are used. One example was using a C++ cryptographic library which was nicely OO. Java's Cryptographic library (JCE) killed it in performance, because Java can inline polymorphic calls, and C++ can't, so thousands of iterations of MD5() or SHA() ran much faster. When I converted to C with a heavily non-OO algorithm, using lots of #define macros, Java got beaten, but the resulting code was no where near as easy to read or maintainable.
C++'s big performance win over Java is templates, I won't argue there. If you use Generic Programming instead of OO programming, you'll win.
If you want to see C++ get it's ass kicked by a real language that supports GC, OO, and GP, look at Ocaml's benchmarks.
Similar threads
