Linked by Thom Holwerda on Sat 8th Oct 2005 18:40 UTC, submitted by anonymous
Java Programmers agonize over whether to allocate on the stack or on the heap. Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs.
Thread beginning with comment 42284
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: MMM steaming Java!
by Simba on Sun 9th Oct 2005 20:05 UTC in reply to "MMM steaming Java!"
Simba
Member since:
2005-10-08

"Have a look at Javac (java compiler (makes byte code)), it has ZERO optimisations not even dead code removal!"

Wrong. javac does remove dead code. In fact, you can make a block of code conditional on a constant, and javac is smart enough to know that the code will never be called if the constant condition is not met, and will remove that code. This is in the cases where javac will even let you include "dead" code. Much of the time, javac will flag it as an error. (Example, you cannot include assignments or executable statements after an unconditional return.)

Also, javac can, when possible, inline methods that are declared as final.

"instead all this is left for the HotSpot stuff to work out."

The only problem with HotSpot right now is that optimizations are not persistant across program executions. Although the word is that they will be in a near future release of the JVM. Optimization can usually be done better at runtime. In fact the JVM can make optimizations that C and C++ compilers cannot even dream of based on the fact that it can profile code at runtime and optimize thins. This is why some algorithms have actually been shown to perform better in Java than in C++. The JVM profiles the code at runtime, figures out what it is actually doing, and optimizes it based on that.

Reply Parent Score: 1

RE[2]: MMM steaming Java!
by on Sun 9th Oct 2005 23:52 in reply to "RE: MMM steaming Java!"
Member since:

"javac is smart enough to know that the code will never be called if the constant condition is not met, and will remove that code."

Ok I was patially wrong, i`ve been playing with this and on DECLARED constants it does work but on say a boolean that is NOT declared as final but is in local scope and is assigned false and does not again change it does not! (this is an easy optimization).
The current javac uses "final" almost as a "optimize me" flag which is not semantically correct, having to declare a local variable as final even if it`s value does not change is nuts, this is what a compiler is for.


"javac will flag it as an error. (Example, you cannot include assignments or executable statements after an unconditional return.)"

Erm that is syntax not optimization ;)

"The only problem with HotSpot right now is that optimizations are not persistant across program executions."

I`ve alway thought the HotSpot compiler/runtime was a great place to do many things, it`s more like running GCC in profile mode then a traditional static AHOT compiler and we really need a way to keep the information created from a execution to be persistant, aslong as the hotspot is always free to rewrite any piece of this information at any point.
Imagine a program that gets better with age (well up to a point) and if this profile information could be exported it may be usefull in analyzing the source code later on.
My only concern is that we may be missing the low hanging fruit of simple static analysis.

Reply Parent Score: 0

RE[3]: MMM steaming Java!
by Simba on Mon 10th Oct 2005 00:25 in reply to "RE[2]: MMM steaming Java!"
Simba Member since:
2005-10-08

"Ok I was patially wrong, i`ve been playing with this and on DECLARED constants it does work but on say a boolean that is NOT declared as final but is in local scope and is assigned false and does not again change it does not!"

There is a good reason for this though. If it did do as you suggest it should, you would potentially break any classes that relied on the class in question if you ever change that value in the future. Thus, every class tha relied on that class would have to be recompiled. Things like this are part of the reason that C++ suffers from what is sometimes called the "fragile base class" problem. This is a problem that Java does not have.

Reply Parent Score: 1