5 ms·
The Black Magic of Java Method Dispatch
- twoodfin 12y agoHotSpot is a pretty sweet piece of technology, with an illustrious lineage back to Ungar and Smith's beautiful Self language[1] and the Strongtalk[2] Smalltalk VM implementation. If this kind of "black magic" excites you, I highly recommend digging into both of these decades-old projects. Terrific link, luu. [1] http://www.cs.ucsb.edu/~urs/oocsb/self/papers/papers.html http://www.cs.ucsb.edu/~urs/oocsb/self/papers/papers.html [2] http://strongtalk.org/history.html http://strongtalk.org/history.html
- agumonkey 12y agoIt's a rite of passage when your college teacher make you trip Java's dispatch.
- oconnor0 12y agoWhat do you mean?
- user_name2 12y agoHe means go to college
- agumonkey 12y agoYou'd never expect such a language to have corner cases on method calling. Makes you realize that something mundane looking can have complex side-effects.
- chopin 12y agoAs one example, I had some humbling experiences with constructors calling overridden methods. The dispatched methods are faced with an incompletely initialized instance in this case.
- suyash 12y agoI've been tripped by my professors on it a few times.
- gsg 12y agoGood article, nice and meaty. mov 0xc(%r12,%r11,8),%eax Interesting choice, won't this be a so-called "slow lea" on recent Intel hardware?
- vardump 12y agoI think the relevant execution unit for address calculation is always available at that point. Not sure without testing, of course. I'm pretty sure the following replacement sequence for just that one instruction would be more expensive regardless: shl 0x3, %r11 ; Multiply by 8 add %r12, %r11 ; Add (heap?) base address to r11 mov 0xc(%r11),%eax ; Indexed + displacement addressing mode xor %r11, %r11 ; Make sure upper 32 bits are cleared for future r11 use Last line (xor) is most likely not necessary, but might depend on how r11 is used in the future. If JVM assumes the upper bits to be always zero, it is needed.
- logn 12y ago> If you have a simple method implementation that does not depend on instance state, it is a good idea to make it static, for both maintainability and performance reasons. Carrying around the class instance just to make the virtual call off it makes life harder for runtime. Also anonymous inner classes retain a pointer to the parent which can impact memory usage. Additionally although not relevant to the code in question, the author's habit of using if/else vs. ternary (or if-only) can have performance and caching implications: http://stackoverflow.com/questions/4706696/which-if-construct-is-faster-statement-or-ternary-operator http://stackoverflow.com/questions/4706696/which-if-construc... http://kennethxu.blogspot.com/2013/10/ifelse-statement-vs-ternary-operator.html http://kennethxu.blogspot.com/2013/10/ifelse-statement-vs-te...
- chopin 12y agoIt should be noted that making things static can impair testability a great deal. For this reason I frown upon static references across component boundaries. Even within components I tend to use dependency injection for this very reason. I fail to see why static methods should be better with respect to maintenance unfortunately the author lacks an explanation of this opinion. I would express the contrary opinion as you can exchange the implementation easier at selected spots.
- logn 12y agoFor some cases. But static methods can be easier to unit test. But if you're concerned enough about performance to care about minute bytecode details (intended audience of the article), I think ease of testing is a lower priority.
- mercurial 12y agoIt depends a lot on what you do with the static method. If it's side-effect free, an Utils class with static methods can be a good way to test some business code without exposing private methods. If it's impure, run away.
- chopin 12y ago
- rewqfdsa 12y agoThe author's style is wooden and insufferable. What is it about Java that attracts people who want to give the impression they are very smart, but who just sound like MBA types when trying to pull it off?