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

F02 Final Exam Review: Virtual Machines

a. garbage collection, portability, messaging/broadcasting
b. type-checking for error detection, alleviates the use of accessors and modifiers, decreases the need for instantiation.
c. garbage collection, because garbage collection requires keeping track of all reference to objects, it is a pretty intensive task.
d. registers are expensive

more stuf...
A. more memory efficient?, and secure

I don't think it's more memory efficient as much as it provideds automated memory management. It's only more efficient if you aren't properly allocating/deallocating memory...

According to the lecture slides about VM's (slide 5) "More memory efficient
Definitely an issue for low-power, low-memory consumer devices".

WRT "More memory efficient
Definitely an issue for low-power, low-memory consumer devices"; I think they mean that when something doesnt use much memory, u may as well not worry about managing ur own memory ESPECIALLY since it would take less time to free up memory since the memory to be free'ed is relatively small

Depends on what you define as efficient. Efficiency when it comes to ease of use, perhaps. However, speed-wise, it'll ever touch C/C++. Remember that VM's main speed bump is the GC, which of course, manages memory.

Even in certain cases, you may need to FORCE the GCer to free up certain space. Certain rendering loops in computer graphics require that you free up memory before the next pass, because the GC might not free it up when you need it to be freed. Automated memory management isn't always more efficient in that respect.

Efficiency can also mean being productive without waste. Freeing only when you need to, seems to be more efficient then keeping track of it automatically, perhaps running a pass of freeing when you don't, in fact, need to. So, it may not more efficient in that case, either.

But, where it is more efficient, is when you compare its easy to use to its productivity. For many applications, it is, ideal. Oh, and apparently because VMs reclaim memory the instance it is not used, so it does lower how much memory is used. This is what I think they mean by efficiency.

Sometimes, lecture slides don't give the full meaning without someone to elaborate what it really means. Correct me if I'm wrong, though. Perhaps I'm just being a little picky? =)

Hmmmm.... interesting. The only point I would probably disagree with you is when you say that freeing when you need to is more efficient than when you don't. If you are doing some processor intensive graphics work and all of a sudden you run out of space what'll happen? In the middle of displaying the picture it'll have to do the garbage collection which slow down (or maybe even stop for a short while) what you are trying to display. If you wait until the last second in my opinion you are asking for garbage collection to occur when you LEAST want it to.

Other than that all of the arguements posed have piqued my interest. Thanks for the insight. By the way my name is Sunil Nicholas.

First, when displaying pictures in a rendering loop, you never should display the picture until it is completely drawn anyways (this is termed double buffering/page flipping). Therefore, whether you GC before, or after(generally you free right after you allocate, not free at the beginning of the next pass), when the GC hits, it shouldn't really matter. You might simply get a "chop" in the frame rate, if anything. One way or another, you will have to free. The only problem is this: (Taken from dispose from java's Graphics class API)

"When a Java program runs, a large number of Graphics objects can be created within a short time frame. Although the finalization process of the garbage collector also disposes of the same system resources, it is preferable to manually free the associated resources by calling this method rather than to rely on a finalization process which may not run to completion for a long period of time.

Graphics objects which are provided as arguments to the paint and update methods of components are automatically released by the system when those methods return. For efficiency, programmers should call dispose when finished using a Graphics object only if it was created directly from a component or another Graphics object. "

Then, the problem of relying on a GC to free memory becomes appearent when you have objects not being used taking up space when they shouldn't be - and this may ultimately lead you to running out of memory.

Conventionally, you draw your graphics to a back buffer, flip the page (show the frame), then you dispose. If you don't have the memory for the graphics in one pass of the rendering loop, then you might as well not be running it ;-)

1. Give three reasons that one might use a virtual machine (and compiling to native code) instead of a compiler to compile directly to machine code.

(a) Portability. A code created in a VM-interpreted language is going to run on any machine that has VM for that language.
(b) Safety. Languages like Java are first compiled down into a intermediate language, which can be inspected and validated by the VM before it is run. A VM-interpreted language, along with additional security configurations in the VM, can make it difficult to write destructive code.
(c) Garbage Collection. People with fancy math degrees and D-R-Period in front of their names have put forth hard work into creating efficient memory management systems that do not require the programmer to deal with memory allocation and deallocation.

2. Give three good and frequent reasons that one might add a primitive to a VM.
(a) A primitive might be added when it is faster to be executed from that primitive.
(b) A primitive might be added when its corresponding implementation (what it does) is used infrequently– not need to define an opcode for the VM to deal with if its not needed.
(c) A primitive might be added when its corresponding implementation is difficult or impossible to do in the language itself (IE, directly interfacing with the video card in some VM-interpreted languages).

3. What takes up the majority of time and effort in a VM (typically)?

Packing or unpacking (boxing or unboxing)–the conversion of bytecode to native code and vice versa– can eat up quite a bit of time for a VM.

4. Why are VMs so often stack-based architectures? Why not have registers?

A stack-based architecture is easy to implement and helps maintain values by always going to the stack to retrieve them. Virtual registers are a silly idea, since real CPU registers exist for speed, being located directly on the die of the processor. Virtual registers might map to locations in memory, to which there is no speed advantage. Finally, if the VM were to take advantage of the real CPU's registers, the VM source code would be less portable. VMs are platform specific, but being able to take one VM and modify it to work with another platform would be substantially altered if register allocation was utilized, since not all CPUs have the same number of registers, or any at all.

Paul Royal

I thought we were told that registers were not used in VM because registers differ across platforms?

Bruce Ota

Links to this Page