 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / July 2007Java Typecasting Internals
What actually happens in JVM code when you execute the following -- snippet ------------------------------ Vector vec = new Vector() MyClass a, b; vec.add(a); *** b = (MyClass)vec.get(0); *** --------------------------------------------- Specifically in the last two (starred) lines, how are the casts to Object and MyClass performed. I'm trying to create a high performance java application and I need to know if casts are prohibitively expensive. Thanks, -Jordan >I'm trying to create a high performance java application and I need to >know if casts are prohibitively expensive. How is a cast implemented? On the left you have a type on the right you have a type. You want to know if the item on the right is an instance of the type on the left to allow the cast to proceed. So that boils down to how could you efficiently implement instanceof. The flat footed way would be to compare the address pointers to the class object in the each side. If they don't watch chase the chain to the superclass on the left. Compare that with the original class on the left. Percolate your way up the chain of superclasses. You could prepare a list of all those left superclass class object addresses and cache them, right next to each other. If the list is very long, you might create a mini-hash lookup or a binary search lookup. Whenever I travel on a ferry, for some reason, my mind chews on the problem of a more efficient instanceof, and some overhead free way to do virtual functions. I play with numbering the classes in a magic way, but the problem is new classes come into being all the time disturbing my carefully constructed tables. It might be interesting to see how HotSpot and Jet have been able to implement it. -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com > The flat footed way would be to compare the address pointers to the > class object in the each side. If they don't watch chase the chain to [quoted text clipped - 5 lines] > very long, you might create a mini-hash lookup or a binary search > lookup. For a class you know how many superclasses it has. So for each instantiatable class, you can have a table of its super classes. So checking if an object is an instance of a class is as easy as loading a pointer to the class data from the instance header, and then testing whether a pointer to the target class is at a fixed offset. Anyway there is a bit more adaptive compiler magic than this, and interfaces are more complex. So if you really are concerned, benchmark your code. The answer should is almost certainly that it makes very little difference. Tom Hawtin On Wed, 04 Jul 2007 12:00:11 +0100, Tom Hawtin <usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone who said : >For a class you know how many superclasses it has. So for each >instantiatable class, you can have a table of its super classes. So >checking if an object is an instance of a class is as easy as loading a >pointer to the class data from the instance header, and then testing >whether a pointer to the target class is at a fixed offset. So for a class instanceof is relatively quick. However that won't work for interfaces. I have heard that instanceof for interfaces used to be much slower, but now it is souped up. I don't know how it works though. -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Wed, 04 Jul 2007 12:00:11 +0100, Tom Hawtin <usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone who said : >For a class you know how many superclasses it has. So for each >instantiatable class, you can have a table of its super classes. So >checking if an object is an instance of a class is as easy as loading a >pointer to the class data from the instance header, and then testing >whether a pointer to the target class is at a fixed offset. I feel such an ninny. I went to add your observation to the entry at http://mindprod.com/jgloss/instanceof.html and discovered it was already there. -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Jul 4, 8:57 am, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > On Tue, 03 Jul 2007 21:53:15 -0000, j...@cornell.edu wrote, quoted or > indirectly quoted someone who said : [quoted text clipped - 30 lines] > Roedy Green Canadian Mind Products > The Java Glossaryhttp://mindprod.com One trick is to cache the class of the last object for which this particular instanceof() was called. Chances are good that the next time the object in question will have the same class. (I mean, in real programs, not in a benchmark designed specifically against the above speculation.) LDV On Tue, 03 Jul 2007 21:53:15 +0000, jsc59 wrote: > What actually happens in JVM code when you execute the following > [quoted text clipped - 4 lines] > b = (MyClass)vec.get(0); *** > --------------------------------------------- The equivalent bytecode would like something like this: new Ljava/util/Vector; dup invokespecial Ljava/util/Vector;.<init>()V astore_1 aload_1 aload_2 invokevirtual Ljava/util/Vector;.add(Ljava/lang/Object)Z pop aload_1 iconst_0 invokevirtual Ljava/util/Vector;.get(I)Ljava/lang/Object; checkcast LMyClass; astore_2 Obviously, casting to Object shouldn't involve any penalties (it knows it's an Object already). The cast to MyClass, however, requires checking the classes for some sort of hierarchy; it is possible that the VM caches the hierarchy into a small hashtable. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.