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 42374
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: MMM steaming Java!
by Simba on Mon 10th Oct 2005 00:25 UTC 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

RE[4]: MMM steaming Java!
by on Mon 10th Oct 2005 01:42 in reply to "RE[3]: MMM steaming Java!"
Member since:

"you would potentially break any classes that relied on the class in question if you ever change that value in the future"

If the variable and it`s effects can not be accessed outside of it`s scope then please tell me how another class could potentially depend on it?
It sounds to me as though your thinking of tightly coupled classes and global/public scoped variables which if your using that to a large degree then you need to be beaten with a big stick!, if a method does something then the implementation does not matter only the result, think of why get/set methods are usefull.
// scope
if (false) {// do stuff}
// end scope
and
// scope
boolean value = false;
if (value) { // do stuff}
// end scope
// scope
final boolean value = false;
if (value) { // do stuff}
// end scope
are the same thing, as long as it`s effects do not escape the scope, this is a trivial example but currently the first and third are optimized away and the second is not.

I`m not saying that we need a fully optimizing AHOT compiler to do every single static analysis trick in the book, just drop dead simple ones like the above (even if it`s for very limited scope it`s still a win).

And there is nothing stopping java having the "fragile base class" problem.
Here`s an example of an article about it for the Java language ;)
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

Reply Parent Score: 0

RE[5]: MMM steaming Java!
by Simba on Mon 10th Oct 2005 02:21 in reply to "RE[4]: MMM steaming Java!"
Simba Member since:
2005-10-08

"If the variable and it`s effects can not be accessed outside of it`s scope then please tell me how another class could potentially depend on it?"

I wasn't clear. What I meant is that you potentially break any derived classes. and the final keyword is gradually going out of favor in Java in favor of runtime optimizations that can do exactly what you suggest.

"And there is nothing stopping java having the "fragile base class" problem."

It's possible of cource, to write a fragile base class in Java. But you have to work at it. In C++ on the other hand, it is the opposite. It is difficult to write a base class that is not fragile.

Reply Parent Score: 1

RE[5]: MMM steaming Java!
by Simba on Mon 10th Oct 2005 02:31 in reply to "RE[4]: MMM steaming Java!"
Simba Member since:
2005-10-08

"this is a trivial example but currently the first and third are optimized away and the second is not."

This is also bad style. If a value is going to constant, it should be declared as such, if for no other reason than that it makes the code self-documenting.

So really, I don't think that the compiler should optimize stuff like this away. And I would not rely on any C / C++ compilers to optimize this away either. In C++ it would have to be declared as const to be optimized away. In C, it would have to be placed inside a pre-processor conditional. Some compilers might do what you suggest. But others won't. So this is bad style, and non-portable code.

Reply Parent Score: 1