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

Sp02 Final Exam Review: Virtual Machines

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.

  1. Quick development with the ability to test in a (more) secured environment.
  2. Dunno.
  3. Dunno.
Chris Verges

1. If you compile directly to native code, you're pretty much throwing any hopes of cross-platform compatibility out the window.
2. As Chris mentioned above, with the VM acting as an extra layer, the end-user is "safer" because the VM can check the code it has received before allowing it to be used. On the other hand, if you run native code directly, who knows what it might do...
3. In a hybrid language where the source code is compiled into bytecode, which can later be translated into native code on a different platform, the file containing the bytecode may be much smaller than either its equivalent source code or native program.


A few other considerations:

Bill Branan

ellie

Okay, but there are several parts to this question, and you haven't got to the hard part yet... Mark Guzdial

Give three good and frequent reasons that one might add a primitive to a VM.

  1. Speed (like the Vectors in Java being VM implemented)
  2. Take advantage of hardware level stuff the VM might not be able to do.
  3. Dunno. (1:38 am)
Chris Verges

1. As Chris mentioned above, speed.
2. In some VMs, native methods are used for infrequently needed functionality. To keep your intermediary language small and fast, you typically want to restrict the range of possible opcodes as much as possible. So it doesn't make sense to give infrequently used functionality (such as closing the VM or opening a socket) its own opcode, rather you want to use the opcodes for the sorts of things that are done thousands upon thousands of times in a given program (such as addition).
3. Also, it makes it easier for third parties to add features that the VM may not internally support. (For example, you want to create a 3D library for your favorite language, but you want to take advantage of the hardware support available on many platforms.)

Okay, but primitives aren't ALWAYS faster than image code! When is a primitive SLOWER? Mark Guzdial

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

In some languages, I know boxing and unboxing is said to take a lot of time, but I'm not sure that's what takes the most time...


"Boxing and unboxing"?... Mark Guzdial

boxing/unboxing : changing between object format and native types, and back, and back the other way...
ellie

I'd have to go with code parsing on this one, I believe that is the piece that generally takes the longest for a VM.

Bill Branan


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

Hardware independent. That way, they can easily be ported over to other hardware. If the hardware supports stacks, great! If not, well, isn't that just two or three registers or something like that? So the actual VM code will translate between the "unicode" of the high level language (eg Squeak, Java) and the lower level machine language (eg Assembler, C, etc). Chris Verges

A few reasons I can think of...
1. Smaller intermediary programs. You don't need to store which register you want to pull the value out of, since there's only one place it can come from: the top of the stack.
2. You know what value will (probably) be used next, leading to possible optimizations inside the VM and easier bytecode verification.
3. In assembly, if you have any important values in registers and you want to call another function, you need to back them up before you do the function call, and then restore them afterwards. With a stack, this isn't necessary: if the function you call pushes values onto the stack, your values are still there. Result? Less work necessary.

Think about memory, and compiler optimization, and RISC vs. CISC... Mark Guzdial

There is no speed advantage to the register-based architecture unless the VM actually takes advantage of the CPUs registers. A stack based system is easier to implement and does not cause a performance hit when compared to a register-based system that uses regular memory.
Matt Lassiter

I think the main point here is that VMs want to allow portability. They don't want to use the machine registers because that would tie the VM to a specific machine architecture, and the point is to not do that. So the only other way to use registers is within the VM, but that just means simulating registers in memory, which buys you nothing because the point of registers is speed, and memory access is slow. So the speed of register use is lost, making it pointless to use them. So, as Matt said, you might as well use a stack.
Bill Branan


Hold on. You seem to know what's going on here, but I think we have a mix up in vocabulary here. You're talking about making the VM platform-specific. That's what a VM is _supposed_ to be. It's an implementation of the language that runs on a _specific_ platform. It's up to the implementors of a particular VM to utilize registers, but the issue here is that they usually don't because they're likely using the registers for their own purposes.

Yeah, you're right. Portability is still an issue to some extent though because VM builders generally prefer to change as little as possible when porting a VM from one platform to another. So that would be one reason to use a stack.
Bill Branan

Someone said code parsing was the thing that took the majority of time and effort with VMs. Is that true? I was thinking memory management.
Rick Giuly
I heard the same person say code parsing takes the most time; I hope it was Mark. Garbage collection is also a killer for run-time performance, but most "compilation" (source to bytecode) time is taken building a parse tree (2130, anyone? anyone? _smack_)




Link to this Page