View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007

Sum01 Final Exam Review: Virtual Machines

a) VM's vs. Compilers?
1. security- it is easy to custom write VM's to stop the user from calling certain functions, ie, Netscape's Java VM
2. portability- if a VM exists for the target platform, porting is relatively easy
3. ease of implementation- some features, like garbage collection are easy to implement in a VM
b) why use primitives in a VM?
primitives might increase speed and require less space?
a 1 byte integer takes less space than an object with a pointer to a 1 byte integer
c) why can't stacks be implemented as contiguous blocks?
not sure. because memory in an object is inherently
non-contiguous? ie, objects are pointer based?
c) the computer's stack instructions are incompatible with some language constructs? say, bytecodes? you couldn't just relinquish the stack evaluation to the CPU architecture... it has to unbox the instructions for the native machine code? Maybe squeak can explain! myobj mess: (SomeClass new)
try popping frames off for evaluating such an expression. SomeClass new evaulates to some value that can be pushed back on the stack but now underneath is the mysterious myobj, which is no good. Obviously this will cause problems with the contiguous stack since such unboxing must take place simultaneously between the message and object. ?? -webb
What other reasons might you have for (a) and (b) ?

On (c), try a different approach: when can a method return, but its temporary variables still be in use? A Java stack, by the way, can perfectly well be implemented using a linear hardware stack. -Lex Spoon

b) Additional reasons to use primitives
Stephen Mallory

(c) From what Lex said above, I'll say maybe it has something to do with static (terminology in squeak?) variables, those which have the life of the program, which are declared in a function. Straight pushing and popping of variables off a contiguous stack would not work if there were such variables in the program. Am I close?

    -axiom

cause if you use a contigious only memory alloc system, you run out of contigious space quickly, and your computer crashes? that close?
jake
(a)
(1) With vm's we can have more built in data structure's that are more complex then the natural primitives you deal with when using a compiler.
(2) Porting code is easier when moving to different architectures. Big/Little Endian problems are pretty much sorted away for you by the VM.
(3) Some architectures are also use more storage for primitives and some OS's will give you more storage as well. When using primitives in a VM, you don't need to worry about the size of primitives as much.
(4) Compilers are hard to port over, VM's are less tedious to port.



(a)Yes, VM's are easy to port, for various reasons. I don't follow the reasoning on the primitive storage size–wanna spell it out. John's (a1) points to a more general issue with using VM's...

(c) Most compiled languages use a contigous, linear stack. They handle static variables by treating them like global variables that only parts of the program may access – i.e., they never get pushed, so they don't need to be popped. They do run out of space if you recurse extremely deeply, but people just live with that. There's still a killer reason nobody is mentioning you can't use this kind of stack in Smalltalk or Scheme.... -Lex Spoon

C) The reason why a contiguous stack does not work in Squeak, is because sometimes a variable might have to live past its return. The best example of this deals with code block passing.
Example (from slides):

x
x:=0.
^[ x:= x+1.]
In this case, the value of x has to persist after its return.


Link to this Page