Am just curious about the way subclasses and superclasses are paired after compilation in byte code. For instance, if we have a superclass called HugeSuperClass and numerous subclasses inheriting its many members, then does the relationship between the superclass and subclass still exist in byte code where the JVM during interpretation goes on fetching bits and pieces from all over the place OR does each class become a kind of independent module ready to be interpreted by the JVM? I guess if the latter would be true then byte code for each class would be Big, considering all the ready Java lib classes and user-defined classes.
If you look below even the bytecode at the actual Klass structure inside the VM, then for most of the common VMs : #1. If A extends B, and B extends C, then A will have a link super pointing to B, and B will have a link super pointing to C #2. B's klass object will have all of C's fields #3. A's klass object will have all of B and C's fields
<a href="http://www.auptyma.com" target="_blank" rel="nofollow">The Peak of Performance</a>
Hypothesis! hehe.. I guess we need a Ranch hand or higher to test it out.
So is it that the JVM goes on fetching things from over the place during interpretation? Maybe that�s not a very bad idea after all! Considering all those wasted GHz lying around. But are we sure that, that is the way how classes are complied into bytecode? Can anyone ponder upon this little question any further and enlighten me in any way�
Originally posted by Rajashekar Subramany: Hypothesis! hehe.. I guess we need a Ranch hand or higher to test it out.
Not really. A rough approximation of the amount of byte-code in a class is the number of bytes in the compiled class file. So: compile your classes and see if they are "big" or "small".
So is it that the JVM goes on fetching things from over the place during interpretation? Maybe that�s not a very bad idea after all! Considering all those wasted GHz lying around.
Keep in mind that modern JVMs don't really work directly on byte code very much - typically much of it is transformed into platform specific machine code during execution.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Oh boy! These are some real good leads on how to proceed with my testing..
Not really. A rough approximation of the amount of byte-code in a class is the number of bytes in the compiled class file. So: compile your classes and see if they are "big" or "small".
Thats kinda crude, but its creative to me.
check out the javap tool to learn exactly what's in a given class file try deleting the .class file for a superclass - can you instantiate an instance of the subclass using only the subclass' .class file?
Thats a great lead.. I'll try 'em out.
Keep in mind that modern JVMs don't really work directly on byte code very much - typically much of it is transformed into platform specific machine code during execution.
I had some knowledge of the process of how the JIT machine gets parts of the bytecode translated, without paying much attention to details, into platform specific machine code, so as to save time. [ January 02, 2006: Message edited by: Rajashekar Subramany ]
It seems that the former is right. The JVM goes on fetching things from all the superclasses during runtime and the complier does not bundle them into a module. Firstly, the smaller subclass has smaller sized .class files and secondly the JVM blows up with a NoClassDefFoundError if I delete the .class file of the superclass.
Ilja Preuss
author
Sheriff
Joined: Jul 11, 2001
Posts: 14112
posted
0
Correct. You can even change the superclass, recompile it, and use the class file with an older class file of a subclass (if you didn't change anything so that the subclass became incompatible).
Kind of off-topic here, but one of the coolest libraries I've played around with lately is Javassist, which is part of JBoss now but can be used independently as well. It lets you programmatically create classes from Java source code fragments (including declaring their superclasses and interfaces etc.), and also gives you access to their bytecode. I've used it to create classes from mathematical expressions entered by the user, and it worked like a charm. A tool like this would be very helpful if you ever considered investigating bytecodes seriously (in addition to javap, as Jim mentioned before). [ January 03, 2006: Message edited by: Ulf Dittmer ]