Is there a boot loader written for booting Java virtual machine without an operating system? As far as I know Java virtual machine can run on a machine by itself, without help of an operating system.
Java defines the guest language, not the host / JVM.
You'd need a JVM written to run on bare-metal of whatever machine you want to run it on. (i.e. to be an OS kernel as well as a JVM, handling interrupts and so on). So there isn't something generic called "Java" that a bootloader could load.
The mainstream JVMs like OpenJDK / HotSpot are not written to work as kernels, only to run under some existing mainstream OSes. But as you found, there are some: Can you run JVM on a computer with no operating system?
Even for a specific platform, the things a kernel needs a bootloader to do may depend on the kernel. There are a few standards, like multiboot for x86, that define a kernel file format that bootloaders like GRUB know how to recognize and load, but otherwise you'd probably expect a bare-metal JVM to come with its own custom bootloader, especially if it's for a platform other than an x86 PC. Or perhaps be bootable as an "EFI application".
Related
The TCG "accelerator" is used by QEMU when requesting full virtualization of a guest with a different hardware architecture (or with -accel=tcg).
TCG is a JIT compiler which emulates the guest architecture set by translating instructions and immediately invoking them at runtime. Portability depends on the list of architectures that TCG supports.
Would it be possible, realistically speaking, to compile an operating system into some efficient IR (similar to Java bytecode) and implement a virtual machine for that bytecode completely in software?
The short answer to "why does QEMU use JIT compilation" is "because it is faster than other ways to do it, like interpreting, but it can still handle any arbitrary guest binary". There has been some work done (not in QEMU itself, but by other projects or research work) on emulation by statically translating guest binaries into code for the host architecture, but this is tricky and you still have to be able to fall back to something like JIT to handle guest binaries that involve self-modifying code or which themselves are JITs (think of running a Java guest inside QEMU).
It is certainly possible to have an operating system which is compiled into an IR bytecode which then executes portably on a virtual machine on a variety of hosts. Historical examples of this include Taos (http://www.uruk.org/emu/Taos.html) and the UCSD p-System (https://en.wikipedia.org/wiki/UCSD_Pascal). Note that you would still here probably want to implement the bytecode-execution engine in such a VM using a JIT, because it's faster than interpreting the bytecode, and there might well be some host-CPU-specific bits of the VM implementation as a result.
However, that sort of portable-operating-system endeavour is an entirely separate idea from QEMU, whose purpose is to run under emulation existing pre-built binaries for a given guest CPU architecture.
I am working on the development of a Java application that loads native library files to perform some calculations. The application uses JNI to load the libraries. This application should work on Windows and Linux environments (on both 32-bit and 64-bit).
During the compilation process, we compile C code to library files (32-bit and 64-bit dlls for Windows, and 32-bit and 64-bit .so files for Linux environments). These .dlls and .so files are included in the distribution file, and are referenced when Java is called by using the -Djava.library.path parameter.
I am now testing the application on a few different machines. I am initially focused on 64-bit Windows environments. The strange thing that I have encountered is that on some 64-bit machines the application loads the correct .dll files successfully, but on some other machines it does not load the .dlls.
I thought that the problem might because of a difference in the processor type between the machines (ie. that the dlls were compiled for one processor type and other processors types cannot use them).
However, it works on one machine, and does not work on another machine that has the SAME processor:
It works on a HP laptop running Windows 7 64-bit, with this processor:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 37 Stepping 5, GenuineIntel
It does not work on a Lenovo laptop running Window 7 64-bit, with this processor:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
My question is: apart from the bitness are .dlls machine/processor type specific in some other way? (I know that the .dll files have to match the bitness of the machine, and that the JVM must also match the bitness of the .dll files)
Or in theory, if a .dll is 64-bit should it run on EVERY 64-bit machine that is using a 64-bit JVM?
apart from the bitness are .dlls machine/processor type specific in some other way?
Very much so. Any compiled binary meant to run under an operating system is both processor and operating system specific, sometimes even down to specific versions of each.
Different processors - even in the same family, such as "x86" - can offer different instruction sets and capabilities. See https://en.wikipedia.org/wiki/X86_instruction_listings for the listing of different variations of just x86 instruction sets and capabilities. If a compiled binary uses a specific instruction, it won't run on a processor that doesn't implement that instruction. For example, if a binary is compiled to use SSE3 instructions, it won't run on processors that don't implement SSE3.
And it's not just limited to hardware, either. Operating system specifics matter, too, literally for starters because the operating system is what starts the running process. So the binary needs to work under the conditions and in the environment of the operating system that started it. A binary designed to work under an operating system will also need to make calls to that operating system to interact with data, devices, or other processes. Different operating systems provide these capabilities in vastly different ways, even to the point of different versions of the same basic operating system doing so in incompatible ways.
And binaries that aren't designed to run under an operating system have to provide very hardware-specific capabilities - ever notice how many device drivers any operating system has? And this excludes any shared object or DLL because by definition they are already designed to run under an operating system.
Or in theory, if a .dll is 64-bit should it run on EVERY 64-bit
machine that is using a 64-bit JVM?
It should be clear by now that the answer is "Not even close".
I am trying to make a use of QEMU in my embedded software development process. I think it will be useful for me to run my code without having to touch the hardware. Especially when the software is sitting in the user-space of Linux. Now, I am trying to get my head wrapped around the big concepts in QEMU.
At what point is QEMU virtualizing the hardware? Can I assume it virtualizes x86 when the host platform is also x86 with virtualization technology built into the processor?
In other words, can I assume QEMU is emulating the hardware when the target platform is not the same as host platform?
It's a general-purpose emulator software (type 2 hypervisor) which can use virtualization when the target and hosts are of the same architecture. In Linux you need to enable the KVM kernel module to be able to use the virtualization technology of the processor.
OpenJDK currently does not have support for a JRE on MIPS processors (there's a port in progress, but who knows how long that will take).
I'm trying to understand how the JRE works, and what is standing in the way of using OpenJDK on our embedded system running Linux on a MIPS processor. If I have a custom JVM that is capable of running on MIPS designed to work with OpenJDK (in this case, I'm referring to JamVM 2.0), is there anything else preventing the JRE from running on the MIPS board? Are any other parts of the JRE platform-dependent?
My understanding is that the JRE is (mostly) composed of two units: the virtual machine, which abstracts the hardware and which is platform-dependent, and the collection of Java libraries which run on the virtual machine and which are not platform-dependent.
To be clear, my questions is: aside from the JVM, is any part of the Java Runtime Environment platform-dependent?
"aside from the JVM, is any part of the Java Runtime Environment platform-dependent?"
That depends on where you place the boundary where the VM ends and the JRE begins. I would consider memory management and code execution as 'the VM', everything more specific part of the JRE.
Thats means every binding to the operating system, be it I/O, Graphics etc. is part of the JRE. Thus the JRE has many platform dependent parts; you usually just don't notice them because your code uses their abstractions (e.g. File, Socket, Window).
So when you say "a port to MIPS" it doesn't mean anything without specifying an OS (ok, your link says Linux); a VM ported to a processor architecture by itself does not make a working java environment. It also requires a port of the native parts of the JRE that allow the java program to actually communicate with things outside the VM; thats where the OS platform comes in.
Since Linux is already supported for x64, the MIPS port should be able to reuse most of the JRE to platform bindings from that.
As i know java programs are able to run on any Operating System.
and there are JVM's for any kind of machines.
I need a JVM that runs on my PC stand alone, and not on my OS (windows or any thing else).
I mean a JVM that acts like a boot, instead of the OS boot
i searched for all versions of JVM on "www.java.com/en/download/manual.jsp", but i did not get the suitable JVM.
the following link helped me a little but that was not enough
http://java-virtual-machine.net/other.html#jvm
my PC CPU is AMD Athlon(tm) 64X2 Dual Core Processor 5200 + 2.69 GHz
any body can help me to find the suitable jvm version ?!
Sure, have a look at JRockit Virtual Edition. As I understand it it's basically a micro kernel especially tailored for the JRockit VM.
From this page:
Java without the OS: JRockit Virtual Edition (VE)
Am I the only one that's never heard of this before? The Oracle JRockit team is looking at eliminating the OS from the stack required to run Java. This product will be called JRockit VE (not out yet)
JavaOS
Good lucking getting hold of it, though, it's nothing more than a historical curiosity.
There are two JVMs that I am aware of, which have this property:
The Fiji WM: http://www.fiji-systems.com/index.html
According to http://rtjava.blogspot.com/2009/11/new-real-time-vm-was-born-fiji-vm.html it also runs on bare metal.
The next possibility is JNode: an open source operating system where most parts are written in Java (the rest in assembly): http://www.jnode.org/
JNode is still beta, though.
No.
There was an idea of making a machine that could run a JVM as an actual machine (non virtualized), similiar to LISP machines, but that idea never took off...
You need a host OS to run a JVM.
Googling "java real machine" might give you some interesting articles.
I've found two: one from 2004, talking about how such a machine could be built and another one, talking about how JVM runs as a real machine on hardware such as mobile devices.
Still, no dice with a plain PC.