I do not see gij listed as one of the Java Virtual Machines on http://en.wikipedia.org/wiki/List_of_Java_virtual_machines and I have not found posts here talking about this either. Can anyone tell me whether gij is a JVM and if not, explain what's the missing in gij or what's the difference? Thanks.
From The Java Virtual Machine Specification:
However, the Java virtual machine does
not assume any particular
implementation technology, host
hardware, or host operating system. It
is not inherently interpreted, but can
just as well be implemented by
compiling its instruction set to that
of a silicon CPU. It may also be
implemented in microcode or directly
in silicon.
So GCJ can rightfully be called a Java Virtual Machine and GIJ, since it is an interpreter, even more so. The only requirement of a JVM is that it executes Java byte code.
If you look more closely at the Wikipedia page, you see GCJ in the bottom box listed in "Foundation and major implementations" of Java Virtual Machines.
I don't see any obvious reason not to call GNU gij a Java virtual machine ... modulo the obvious point that it could not ever be validated due to Oracle's stance on the TCK.
I'd say this is a "bug" in the Wikipedia list rather than a reflection on gij.
(Just looking through the list, I found and fixed another bug. It said that JNode used GNU Classpath, which it hasn't done for a few years now. If the list can get that wrong, it can be wrong about other things too.)
Related
I think the major feature of libvirt is abstract the different target, but if I only use kvm/qemu, what I can get from libvirt ?
There is quite a large set of benefits of libvirt, besides just hypervisor abstraction. Rather than list them all here, check out the blog post I wrote about this a few years back.
https://www.berrange.com/posts/2011/06/07/what-benefits-does-libvirt-offer-to-developers-targetting-qemukvm/
Everything listed there is still relevant today, and we've added some benefits since then, in particular running QEMU in separate mount namespace to isolate QEMU from the host /dev nodes.
the use of this abstraction layer becomes very handy when you start to script or automate KVM deplyments but ...
The main added value in the KVM QEMU setup is the Live Migation of a Virtual Machine to an ohter Hardware with Hypervisor.
I understand what trap and emulate is, however I'm struggling to understand what binary translation is and how it differs from trap and emulate. I'm very new to this topic and am trying to understand this introduction from a paper from 2006:
"Until recently, the x86 architecture has not permitted classical trap-and-emulate virtualization. Virtual Machine Monitors for x86, such as VMware ® Workstation and Virtual PC, have instead used binary translation of the guest kernel code. However, both Intel and AMD have now introduced architectural extensions to support classical virtualization."
I also don't understand what "classical virtualization" is in the context trap and emulate vs binary translation. Any help understanding these terms would be appreciated.
I think this link will help you. I have tried to summarized it, for more information refer the link.
Whenever the guest operating system tries to perform one of these privileged operations, the processor will "trap" the instruction and hand over control to the host operating system or hypervisor, so that it can do the required operation and then return control back to the guest. But most real-world instruction sets, including x86, were not designed with virtualization in mind. As a result, there are privileged instructions that do not have any corresponding trap facility.
Binary translation addresses this problem directly. Instead of depending on the processor itself to detect the privileged instructions it uses virtualization software that inspects the instruction stream in software and whenever the virtualization software detects a problem instruction, it rewrites it on-the-fly,typically replacing it with a kind of manual trap, that will hand over control to the hypervisor at the appropriate moment. Hope this helps you.
All,
I'm attempting to estimate the effort to port an app developed on Windows (.NET) to Linux (Mono). I came across the MoMA tool, which attempts to look through my .exe and find potential areas of incompatibility. Most of my issues appear to be centered around get/set of network settings, getting network info, etc. (Object ManagementBaseObject.get_Item and set_Item. etc).
In almost all of the cases, the Mono functionality is listed as "ToDo". For estimation purposes, is it safe to assume most/all of these have some kind of workaround? I would imagine this type of basic networking support must be included in the latest version of Mono. Or should I assume none of this is currently available and I would be stuck waiting for it to be implemented (or be forced to implement it myself)?
Thanks,
Dan
First,see Mono Compatible Networking/Socket Library. Also,take a look on Cross-Platform Network Applications with Mono. You can start with C# Network Library.
Maybe this is a cross-system issue, and maybe not. But I am just working on Mac OS X, therefore I focus on Cocoa.
As my title described, can I detect whether my application is run in an virtual environment programmatically? (not only vmware, but also some other virtual environment like Sandboxie in Windows)
There won't be any native Cocoa API's to specifically ask if you are running in a virtual machine vs real hardware.
However, if you know the potential environments you are running under you should be able to use IOKit to query the hardware of the virtual machine.
Virtual Machines will have considerably different hardware than a real Mac so you should be able to detect a real Mac vs a VM based on hardware configuration.
I can not give you any direct code, however, there is a section on Apple's site that discusses accessing hardware with IOKit in general:
https://developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/AccessingHardware/AH_IOKitLib_API/AH_IOKitLib_API.html
IOKit is an advanced subject so if you do not have a lot of experience with the lower-level APIs you may find it a bit confusing as compared to Cocoa.
Maybe you can cross-compile virt-what and make use of it.
In addition to I/O Kit you could use C POSIX functions. Check the man pages.
If hardware support is a must for virtualization, how can Java Virtual Machines run on machines without support for virtualization ? Or is JVM not a virtual machine ?
A JVM is not virtual in the same sense as a VirtualBox or VMWare virtual machine. It is a 'machine' that implements the Java bytecode, not a virtualized version of actual hardware.
The term-of-art 'virtual machine' was coined a very long time ago for the following scenario:
make up a computer, like Knuth's MIX.
write a computer program that implements the made-up computer.
run programs
When this virtual machine runs, it's a completely ordinary program, running completely in user mode. It needs no special help from the hardware or operating system to work reasonably well. This is especially true of the JVM, since the Java byte code does not deal with low-level hardware I/O or other things which are hard to simulate.
Later, historically, (to pick a particular instance), IBM invented VM/370. VM/370 uses the other sense of the term 'virtual machine'. In this later sense, the hardware and operating system cooperate to allow a single physical machine to host multiple virtual instances of (more or less) the same architecture, in which multiple copies of the whole operating system are written as if they are running on more or less bare hardware. Later, the X86 was designed with features to facilitate this.
So, yes, any virtual machine is making use of some physical hardware, unless you implement it with pieces of paper passed around a table (pace John Searle). But when the virtual machine bears no resemblance to the machine it is running on, then there's no need for special help from the operating system and hardware, and no need for anything as complex as VM/370, or VMware.
If hardware support is a must for virtualization, ...
Let me stop you right there :-)
There is a difference in concept between the JVM (software virtualization) and (for example) a VMWare VM (hardware-assisted virtualization).
The JVM (and other software-based VMMs such as the ones that allow to to emulate x86 on Solaris hardware - I think Bochs and possibly DosBox fall into this category) runs like any other application, using the operating system to gain access to the hardware, or emulating its own hardware purely in software.
VMWare, and the other VMMs optimised for speed, rely on hardware support. In other words, they run on the hardware as if they have full access to the hardware and, only when they try to do something they're not supposed to does the OS captures that attempt and fake it.
That's why VMWare runs so much faster than the software-only emulators. It's because, for the vast majority of the time, it's actually running on the real hardware.
The JVM is a virtual machine, but it doesn't require any additional support from the Operating System. Instead of virtualising instructions for a particular CPU it executes java bytecode.
The JVM is a virtual machine for running Java, in other words it emulates a machine which would be capable of running java. It is a confusing choice of names, but it comes from the general meaning of "machine" not from the more common Virtual Machine meaning.
The JVM, like a regular VM emulates the execution of instructions, but in the case of the JVM the instructions being emulated are Java Instructions, and in the case of a VM they are Hardware Instructions as would be executed by an OS running on the same hardware.
Yes the JVM does access hardware, however this is why you install a MAC or WINDOWS JVM since the instructions are translated by the JVM and acted upon depending on the installation of the JVM, for example, open file dialog on mac opens the mac dialog and windows JVM opens the windows dialog.
So its not being virtualized by the system, but the bytecode is being virtualized by the JVM you installed. It's basically like an application that reads something(bytecode) and does something(access hardware, or other stuff).
It should be noted that nothing stipulates that a JVM does not (have to) have HW virtualization access. There are notable exceptions, but to which the answered poster alluded, few CPs exist that run Java bytecode natively. Maybe someday a Java bytecode HAL or TIMI will be commonplace to put the JVM into the same class as the formalized HW virtualization?