>The JIT compiler can do things that a static compiler can't. The more >frequently a method is used, the more optimisations can be applied, >such as inlining other methods and branch table reorganisation. This >results in code which can actually be faster than statically-compiled >code.
Does that mean that JIT compiled code is being monitored for its efficiency and is kind of recompiled every so often? >That *is* meant to be an ironic statement, isn't it? Well, no. >If you use malloc() in a C program, then it's a good idea to >care about free() as well, otherwise you can end up out of memory. There is no need to use malloc() in C or ALLOC in PL/1. You can write your program using only automaic variables. The runtime takes care of the memory management. This is what I was referring to. I admit that todays JVMs have much more sophisticated memory management code than HLL runtime environments provide. But the OPs argument I was responding to was that this very JVM memory management was a reason against compiling Java code. My argument is that Java's memory management concept doesn't have to be any different between running interpreted versus running compiled code. -- Peter Hunkeler Credit Suisse ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
