Related
I have been working to connect to a device to a dongle using OpenThread.
I am looking for a .Net Implementation of Openthread.
There is a Zigbee implementaion for .net called ZigbeeNet.
Looking at ZigbeeNet it appears to be a library to interface with Zigbee device over a COM port, so I'm assuming you're also targeting .Net on Windows. The equivalent would be a Network Co-Processor host implementation in OpenThread terminology and unfortunately there isn't a direct .Net implementation. Microsoft implemented a Windows 10 NCP driver which would have been a good starting point, but unfortunately they've dropped support. It still may work but YMMV.
It is possible to run the UNIX host wpantund in a VirtualBox VM and run your .Net application in the guest.
JVM and CLR are virtual machines. Similarly to bare metal computer machines, they provide virtual machine languages.
On real computer machines, we have operating systems, which provide system calls and APIs. For example the famous book Advanced Programming Unix Environment describes the APIs provided by Unix and Linux. Windows, however, provide different APIs.
On top of virtual machines like JVM and CLR, is there something which
plays the role of an operating system, and
provides programming APIs?
If there is nothing playing the role of an OS on virtual machines like JVM and CLR, what provides programming APIs (such as those in Java, C#, ...) similar to OS APIs?
Note: I am asking about VMs and on top of them, instead of what is underlying them. Do VMs not run some virtual OS on top of them? If there is no, why is there no such a need?
Thanks.
There are two kinds of virtual machines: system virtual machines and process virtual machines. System virtual machines provide a virtualization of complete instructions sets including user-mode instructions and kernel-mode instructions and therefore they can run operating systems. Process virtual machines virtualizes user-mode instructions and, usually, some system calls (such as those for managing threads, memory, and files) and therefore can only run applications or processes. That is, on top of a single process virtual machine a single app or process can run. The JVM and CLR are process virtual machines.
While in theory it is indeed possible to develop an OS to run on a process virtual machine, this is practically not useful because the performance of the programs that will run on that OS will be terrible due to the excessive layering in software.
Generally, system and process virtual machines themselves are not considered to be operating systems. However, process virtual machines do not necessarily require an OS to run on and may run on a bare-metal computer. The .NET Micro Framework is an example of such VM. Such VMs are sometimes called operating systems. Some virtual ISAs or a subset thereof have been implemented completely in hardware similar to x86 and ARM. One could develop operating systems to run on them. They are almost never used in industry because of their low performance.
An "operating system" is a a large, fuzzy ball of hairs. You got the hal, kernel, userspace... do we count some userspace libraries (typically libc) too?
With squinting you can find some comparable concepts in the JVM/JRE but generally a JVM runs on top of a bona-fide operating system and thus does not reimplement all aspects and instead simply provides platform-independent abstractions over facilities that you can find on almost all systems.
For example these days Thread usually is just java representation of native OS threads, but a JVM could choose to implement thread scheduling in userspace, and in sun's JVM did back during 1.1 times and some other JVMs still do today.
I'll answer this from the perspective of Java since I have no in-depth knowledge of .Net. I would assume, however that the CLR and JVM are similar from this point of view.
Let's start with an operating system. The purpose of this is to abstract away the hardware specific interfaces as well as providing a runtime environment for processes.
The OS uses device drivers to provide a uniform interface to similar devices (like the processor, memory, disk drives, network cards and so on). The OS uses system calls to allow user-level code to interact with these devices. If you wrote code in C you will call 'open' then 'read' and 'write' to the device before calling 'close'. The 'ioctl' (IO control) system call is also used a lot for device control. Each OS provides a standard set of these system calls (you can run Linux on an Intel or ARM processor, but you have the same set of system calls for each distro). Incidentally, this is also how Docker works by using a standard set of system calls to enable containers to be moved from one platform to another without problem.
The OS also provides the ability to run multiple processes simultaneously. With newer, multi-core machines this really can happen in parallel but the OS also uses scheduling to share a CPU between multiple processes or threads. By switching processes or threads very quickly this gives the impression that things are happening simultaneously, even on a single processor.
Now let's look at the JVM, which is a user-level process (from the OS point of view so just like any other user application). This has been designed to abstract away CPU and operating specific functionality from the Java application. The bytecodes generated by the Java compiler do not contain any system calls. If you look at the bytecode instruction set (defined in the Java Virtual Machine Specification) you will find that the instructions provide many familiar low-level features such as loading a register, bit manipulation and so on. In addition, there are many instructions that are higher level and relate more specifically to Java; things like invokestatic that invokes a static method on a class, monitorenter. monitorexit for locking, newarray and so on.
The JVM takes these bytecodes and converts them from a CPU- and OS-independent form (that of a Virtual Machine) into the instructions for the specific CPU architecture and OS that the JVM is running on. In some cases this can be a one-to-one mapping (for things like bitwise operators), but can often be much more complex and involve the use of system calls to open files, access network interfaces, etc. The JVM also uses the OS to deal with threads created by the application. In the very early days of Java operating systems like Windows 95 did not have the concept of threads within a process so the JVM had to provide it's own implementation (this was called green threads and performed pretty badly).
To summarise the JVM takes the platform neutral bytcodes of the class files it is executing and converts them to the apprporiate native CPU instructions and system calls to make the application run. The JVM does not provide any traditional OS services, it just uses them.
Would the JVM (and probably also the CLI) be considered a virtual machine (the equivalent of the x86 in a "normal" program stack) or a virtual OS (the equivalent of Windows)?
Strictly speaking, it is a virtual machine, ie: it executes a special low-level language (similar to x86 ASM. CLI uses MSIL, JVM uses "byte codes") and translates them into the target machine's op-codes (x86, x86_64, ARM .. etc.) for execution on the host CPU.
It also manages marshaling (ie: correct handling and passing through of variables to native memory stack/heap) to allow function calls from inside the managed world to the outside OS on which the VM runs.
Practically though, neither the JVM nor the CLI alone are very helpful except for automated garbage collection and CPU-architecture-independence, but they are complemented by a large base library (the Java classes, or the .NET BCL) which allows you to do many platform-y things without having to call platform specific APIs and use marshaling manually for everything.
That's why there is a different Java Runtime Environment for each OS. Each one's JVM translates to a specific CPU arch, and uses different platform specific-APIs to accomplish what the unified base library exposes to you as a friendly API inside the managed world.
Hope that helps you.
The jvm is considered a real computer, only not realized in hardware. The machine has it's own storage capacity, it's own memory model, it's own specific behaviour of it's central processing unit and it's own internal machine code. This machine is extendable with new possibilities and modules that are represented with classes, API's, etc...
It has it's own stack based architecture, like most virtual machines.
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?
I have two Java Programs each running in its own JVM instance ? Can they communicate with each other using any IPC technique like Shared Memory or Pipes ? Is there a way to do it ?
Yes; D-BUS and Pipes are both easy to use, and cross-platform. D-BUS is useful for general message-passing IPC, and pipes for sending bulk data.
You can also open a TCP or UDP socket on localhost, if you need to support multiple clients connecting to a central server.
I also found an implementation of UNIX sockets in Java, though it requires the JNI.
http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp
Java Remote Method Invocation (Java RMI) enables the programmer to create distributed Java technology-based to Java technology-based applications, in which the methods of remote Java objects can be invoked from other Java virtual machines*, possibly on different hosts. RMI uses object serialization to marshal and unmarshal parameters and does not truncate types, supporting true object-oriented polymorphism.
Sure. Have a look at RMI or a Shared Memory concept like Java Spaces.
Use MemoryMappedByteBuffer in Java NIO for sharing memory between processes.
There is a fairly new initiative for language-agnostic IPC of columnar (i.e. array-based) data from Apache called Plasma.
As of yet (Sept '17) there are no JVM bindings, but as the project is backed by the likes of Spark, I think it won't be long before we see an implementation.
My understanding however is that there is not a general IPC system, as it is geared toward sharing arrays of primitives like double,long, for scientific computing, rather than classes/objects; though I could be wrong here.
On the plus side, it's also language-agnostic, so you could use it to communicate with another (non-JVM) runtime. However, the OP did ask for Java IPC so this could be irrelevant.