Hacker News new | past | comments | ask | show | jobs | submit login

I am very disappointed that this.getSize(); at the end fixes the issue. Since it has no side effects and the value is never used anywhere, I would expect the compiler to remove that call.



Me too. I would fully expect the JIT compiler to remove this call unless it's more complicated than it sounds. I don't think this is a real fix.

I work on IBM's JIT compiler. We had to do something similar to fix this problem in DirectByteBuffer a few years ago, by adding a call to a magic method called keepAlive. To make this work, we had to teach the JIT to handle this method specially, or else it would have ripped it out, and the fix would have had no effect.

[These are my personal opinions, not those of my employer.]


The Java compiler does almost no optimization. I think it's an idealistic thing: All optimization is supposed to be done by the JVM. Personally I think that sounds stupid.


This is a very sound approach. The main benefit is that all JVM languages can utilize optimizations if the optimizations are in the JVM, thus logic duplication is reduced.

Also, please note that both Clang and GCC use the same approach, except in their cases the programmer typically does not see the intermediary code (which is LLVM for Clang, and a family of intermediate languages for GCC).

http://en.wikipedia.org/wiki/Intermediate_language


Except that, as evidenced by this case, the JVM isn't doing the optimization either!

(Also: it's not a stupid approach. Due to the way the JVM loads things, most of the time you don't know that any particular method won't be overridden later by something that does, in fact, have side effects. There are very few optimizations that could actually be done by the Java compiler.)


The compiler doesn't (shouldn't) know what the runtime system will look like, so it cannot make optimizations as safely or effectively as the JVM can.


Except that, as evidenced by this case, the JVM isn't doing the optimization either!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: