Develop Reference

What does the OS do when you run java bytecode? How it interact with the JVM?

I have been studying Operating systems in my free time, but I am confused about how it works with Java & the JVM.
Some questions
when running the java bytecode using a command like java file.class:
I understand that JVM optimize and interpret or perform JIT of the program
How does the JVM get CPU allocation for doing these in a multi-threaded application?
My assumption: In each thread of this application, they all use the same per-process JVM to perform these tasks. (Is this correct?)
What is the role of the operating system with the JVM, what interaction do they have?

(image from Wikipedia)
JVM is just an app
The Java Virtual Machine (JVM) as seen in the OpenJDK project is just another app, usually written in C and C++, sometimes written in Java.
From the point of view of the host operating system, running a JVM is just like running a word-processor, a spreadsheet, or a web browser. All of these apps are large, consuming much memory and spawning threads.
As someone commented, a JVM technically is any software and/or hardware that complies with the official specifications. Indeed, there have been attempts at building hardware chips that knew how to execute Java butecode (see Jazelle and others) but they did not succeed afaik. In practice today, the JVMs we download from Oracle or AdoptOpenJDK or other distributors are simply C/C++ apps that run like any other app on your Mac, BSD, Linux, Windows, AIX, Solaris, or similar machine.
I understand that JVM optimize and interpret or perform JIT of the program
HyperCard from Apple is vintage software similar to Java in that it too executed code internally through an interpreter with a JIT so that repeated runs of the same code blocks would suddenly run faster. HyperCard too was just another app from the point of view of the Mac operating system.
How does the JVM get CPU allocation for doing these in a multi-threaded application?
By scheduling threads on CPU cores like any other app. Word-processors use threads for writing to storage in the background and for re-rendering the document on the background. Web browsers might allocate threads for handling each web page in separate windows/tabs.
In each thread of this application, they all use the same per-process JVM to perform these tasks. (Is this correct?)
Yes, with OpenJDK, you will see one process on your OS for the JVM. All the threads of all the Java apps running within that JVM are housed within that single OS process. However, as someone commented, these are mere implementation details. People are free to implement a JVM as they see fit, in any manner they choose, as long as they comply with the Java specifications.
See the source code
OpenJDK is open-source. So if you are really curious, peruse that source code. Note that you will find areas of code specific to each OS, such as macOS versus Linux versus MS Windows, on each CPU type, such as x86 or ARM or SPARC or such, where the JVM interacts with the host OS.

Why is Java platform independent?

When I used C++ programs, I needed Turbo C complier; and when I have a Java program, I need to have JVM. Still C++ isn't platform independent, but Java is!
If any Java program require a JVM running in order to execute, why does Java is said to be Platform Independent?

Java is operating-system independent because it runs on the Java platform (the JVM): The mantra is "write once, run anywhere" because you write your code using the JDK API, compile that once, and it runs on any operating system that has a JVM available. You write your code, wrap it up in a jar, and that jar runs wherever you want to use it, within reasonable bounds. The job of the JDK and JVM are to abstract away the differences in environments.
In contrast, particularly back when Java was created, writing C or C++ for multiple operating systems was a big pain and usually required additional toolkits (of course, the JDK and JVM are a toolkit of sorts), and even today still requires at least recompiling for the target system.
There's nothing magic about Java's OS-independence. It would be entirely possible to build the same thing for C or C++: Compile to an intermediary form, provide a runtime that knows how to interpret or recompile that intermediary form for different environments and provide a library that abstracts away environmental differences. Java just...did that, with its own spin on the language. Later, so did the .Net platform.

No software is really "independent". Eventually, your program has to call the underlying OS in order to make some basic operations, like allocating memory, create new threads etc.
The way to achieve an executable which is "cross platform" is to create specific executable for each OS. Common practice is to write different code for each OS, and then "hide" it in a cross platform interface and compile the relevant code to the relevant OS. For example, std::thread is "cross-platform" to the user who uses this class, but behind the scenes it will call different functions based on the OS which was specified on compile time (such as CreateThread on Windows, but pthread_create on *nix OS's).
So basically, the JVM is a C/C++ executable that was written with different set of functions for each OS, and was compiled separately for each OS. A JVM executable which works on Linux, will not work on Windows, and vice-versa.
That JVM compiles .class files to machine code based on the OS and CPU it currently operating on, so that's why Java programs can "run anywhere".
But basically, it's a lie. It's like saying a human being can live on Mars....
if he lives inside a sealed spaceship with proper temperature, water, food, air and sunlight supply
So Java program can run anywhere.... if the JVM already is installed and running on the computer.

Firstly, I'd like to link to this question which has a lot of good information.
https://softwareengineering.stackexchange.com/questions/85175/what-is-the-exact-meaning-of-platform-independence
In the question above are comments about what it means to be "Platform independent," but the one thing I wanted to mention, but is summed up nicely here is
You're right, platform independence means that the same program works on any platform (operating system) without needing any modification.
The code we write is known as "Write once, run anywhere" or as someone else said "run once, test everywhere."
Our Java code SHOULD run everywhere, but sometimes there are little native bugs that cause issues i.e., someone was having issues with printing on Mac OSX with JavaFX-8 Printing, while it works fine on Windows. There was also a bug report on this to fix this "Mac specific Java issue."
So.... For the most part, the underlying JavaSE code SHOULD work across all platforms.....
** however, if you do have an Application running on multiple computers and work with the File System, you will have to do checks to understand which OS you are working with i.e., (System.getProperty("os.name").contains("Windows")); **
more info on that here https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
There is also another thing to note.
Certain components do not work cross platform, i.e., JavaSE vs JavaEE. JSP/JSF is what is used in JavaEE, on the web, that is specific for running code on a server, and in a webpage, but cannot be used in the Desktop (to my knowledge).
However, JavaSE has GUIs such as Swing, and JavaFX, which also cannot work on the web, either in the Client, or in the Server.
Android has it's own set of commands and things it can/cannot do, and other "Platforms" have specifics to it as well.
Overall, the underlying Java Architecture is what is used across all platforms, where certain "Java Specifics" are used in certain platforms i.e., JSP.
So what does Java do differently?
In the case of Java the application runs in a Java Virtual Machine which itself isn't platform independent. This has to be the interface between the actual machine (operating system) and the Java code you've written.
I am not really knowledgeable that much of the JVM, but it seems that each JVM is specifically tailored to each "Platform" (Which is why there are soo many versions to install), and does a lot of heavy lifting in the background, whereas C you might have to do this all yourself (not really sure how it works), for each OS.
Want a JVM for Windows? Np... Linux? Np.... That new car you just bought with all that fancy tech in it? JVM for that.... Or how about that new parking meter where you just parked your car? Yeah, there's one for that too...
For example, here is an Answer from this site on how Java is converted to Dalvik for Android.
https://stackoverflow.com/a/24570735/3599960
Hope this helps and makes sense.

C or C++ program gets compiled into native-code which is close to the metal where metal is the OS (earlier it could be hardware also in DOS era). There is no further re-compilation necessary to run the executable on target platform. But, a developer must build executables for all platforms he/she indents the program should run on.
It doesn't just mean different OSes, but bit-ness of particular OS. For example a 64-bit binary (EXE) cannot run on a 32-bit OS (vice-versa is possible, mostly, however). Here Java/.NET and other platform virtualization engine are boon for the developers - they just build once (for example "AnyCPU" for C# module), and don't need to give multiple binaries (EXE files). The runtime installed on given OS would re-compiler (JIT - Just In Time compilation).
I'm not sure about Java, but a.NET program can be compiled into specific platform. It is also possible by the .NET engine to JIT compile the intermediate (or byte-code in Java) into native format just once (and keep the EXE for direct run). The advantage is that .NET JIT compiler can take advantage of current hardware and latest CPU instructions, which C++ program cannot (it won't have JIT/re-compilation).

Why operating systems are not written in java?

All the operating systems till date have been written in C/C++ while there is none in Java. There are tonnes of Java applications but not an OS. Why?

Because we have operating systems already, mainly. Java isn't designed to run on bare metal, but that's not as big of a hurdle as it might seem at first. As C compilers provide intrinsic functions that compile to specific instructions, a Java compiler (or JIT, the distinction isn't meaningful in this context) could do the same thing. Handling the interaction of GC and the memory manager would be somewhat tricky also. But it could be done. The result is a kernel that's 95% Java and ready to run jars. What's next?
Now it's time to write an operating system. Device drivers, a filesystem, a network stack, all the other components that make it possible to do things with a computer. The Java standard library normally leans heavily on system calls to do the heavy lifting, both because it has to and because running a computer is a pain in the ass. Writing a file, for example, involves the following layers (at least, I'm not an OS guy so I've surely missed stuff):
The filesystem, which has to find space for the file, update its directory structure, handle journaling, and finally decide what disk blocks need to be written and in what order.
The block layer, which has to schedule concurrent writes and reads to maximize throughput while maximizing fairness.
The device driver, which has to keep the device happy and poke it in the right places to make things happen. And of course every device is broken in its own special way, requiring its own driver.
And all this has to work fine and remain performant with a dozen threads accessing the disk, because a disk is essentially an enormous pile of shared mutable state.
At the end, you've got Linux, except it doesn't work as well because it doesn't have near as much effort invested into functionality and performance, and it only runs Java. Possibly you gain performance from having a single address space and no kernel/userspace distinction, but the gain isn't worth the effort involved.
There is one place where a language-specific OS makes sense: VMs. Let the underlying OS handle the hard parts of running a computer, and the tenant OS handles turning a VM into an execution environment. BareMetal and MirageOS follow this model. Why would you bother doing this instead of using Docker? That's a good question.

Indeed there is a JavaOS http://en.wikipedia.org/wiki/JavaOS
And here is discuss about why there is not many OS written in java Is it possible to make an operating system using java?
In short, Java need to run on JVM. JVM need to run on an OS. writing an OS using Java is not a good choice.
OS needs to deal with hardware which is not doable using java (except using JNI). And that is because JVM only provided limited commands which can be used in Java. These command including add, call a method and so on. But deal with hardware need command to operate reg, memory, CPU, hardware drivers directly. These are not supported directly in JVM so JNI is needed. That is back to the start - it is still needed to write an OS using C/assembly.
Hope this helps.

One of the main benefits of using Java is that abstracts away a lot of low level details that you usually don't really need to care about. It's those details which are required when you build an OS. So while you could work around this to write an OS in Java, it would have a lot of limitations, and you'd spend a lot of time fighting with the language and its initial design principles.

For operating systems you need to work really low-level. And that is a pain in Java. You do need e.g. unsigned data types, and Java only has signed data types. You need struct objects that have exactly the memory alignment the driver expects (and no object header like Java adds to every object).
Even key components of Java itself are no longer written in Java.
And this is -by no means- a temporary thing. More and more does get rewritten in native code to get better performance. The HotSpot VM adds "intrinsics" for performance critical native code, and there is work underway to reduce the overall cost of native calls.
For example JavaFX: The reason why it is much faster than AWT/Swing ever were is because it contains/uses a huge amount of native code. It relies on native code for rendering, and e.g. if you add the "webview" browser component it is actually using the webkit C library to provide the browser.
There is a number of things Java does really well. It is a nicely structured language with a fantastic toolchain. Python is much more compact to write, but its toolchain is a mess, e.g. refactoring tools are disappointing. And where Java shines is at optimizing polymorphism at run-time. Where C++ compilers would need to do expensive virtual calls - because at compile time it is not known which implementation will be used - there Hotspot can aggressively inline code to get better performance. But for operating systems, you do not need this much. You can afford to manually optimize call sites and inlining.

This answer does not mean to be exhaustive in any way, but I'd like to share my thoughts on the (very vast) topic.
Although it is theoretically possible to write some OS in pure java, there are practical matters that make this task really difficult. The main problem is that there is no (currently up to date and reliable) java compiler able to compile java to byte code. So there is no existing tool to make writing a whole OS from the ground up feasible in java, at least as far as my knowledge goes.
Java was designed to run in some implementation of the java virtual machine. There exist implementations for Windows, Mac, Linux, Android, etc. The design of the language is strongly based on the assumption that the JVM exists and will do some magic for you at runtime (think garbage collection, JIT compiler, reflection, etc.). This is most likely part of the reason why such a compiler does not exist: where would all these functionality go? Compiled down to byte code? It's possible but at this point I believe it would be difficult to do. Even Android, whose SDK is purely java based, runs Dalvik (a version of the JVM that supports a subset of the language) on a Linux Kernel.

What is the role of the OS when JVM executes a Java application? And why do we need the OS?

I have done some reading on the internet and some people say that Java application is executed by the java virtual machine (JVM). The word "execute" confuses me a little bit. As I know, a non-Java application (i.e: written in C, C++...) can be executed by the Operating system. At the lower level, it means the OS will load the binary program into memory, then direct the CPU to execute instructions in memory.
So now with a JVM, what would happen? As I know, JVM (contains a run-time environment) would be called first by the OS. From that point on, the JVM will spawns one (or many) threads for the application. I wonder if the role of the OS comes into play any more? It seems to me that the JVM has "by-passed" the OS and directly instruct the CPU to execute the application. If so, why do we need the OS?
Taking a little bit further, the JVM will use its JIT to compile the application's byte codes into machine codes, then execute those machine codes. Since it is already machine codes, do we need the JVM any more? Because instead of JVM, the OS can be able to instruct the CPU to execute those machine codes. Am I making any mistake here?
I would like to learn more from people here. Please correct me if I am wrong. Thank you so much!

We need the OS for all the things a C or C++ program would. The JVM does a few more things by default, but it doesn't replace anything the OS does. The only difference might be that sometimes you have Your Code [calls the] JVM [calls the] OS, or with compiled code you can have Your Code [calls the] OS
Similarly in C++ you might have Your Code [calls the] Boost [calls the] OS.
When your program is running in native code, it doesn't need the JVM as such. This is good because the JVM knows when to "stand back" and let the application run. However, not all the program will be compiled to native code for the rest of the life of the application, so you still need it.
Its is possible to use kernel by-pass devices/drivers with JNI, but Java doesn't directly support this sort of feature.

It seems to me that the JVM has "by-passed" the OS and directly
instruct the CPU to execute the application. If so, why do we need the
OS?
All C/C++ binaries (not just the JVM) run directly on the CPU. Once running, these programs can call into more machine code provided by the operating system to do useful things like reading files, starting threads, or using the network.
The JVM translates a Java program into instructions that run on the CPU. Behind the scenes, though, Java's threads, file i/o, and network sockets (to name a few) all contain instructions that call into the code provided by the operating system for threads/files/etc. This is one of the reasons you still need the OS.
Since it is already machine codes, do we need the JVM any more?
The JVM provides features that you don't get from the JIT compiler. At the end of the day the JVM is just running a lot of machine code, but not all of that machine code comes from the JIT (or from the interpreter). Some of that machine code does garbage collection, for example. That's why you need the JVM.

The underlying base O/S still has to do almost everything for the JVM, not least:
Input / Output
Memory management
Creation of threads (if using native threads)
Time sharing - i.e. allowing more than one process to run
and lots more besides!

Well, I want to keep this simple.
How you coded in ZX Spectrum, that is in old days, when really you don't use OS (even before DOS era, in pre-PC era). You write your code, and you have to manage all. In many cases there were no compiler, so your program was interpreted.
Next, it was realized that OS is great thing and the programs became simpler. Also, compiler was in broader use. I am talking about C++, for example. In those programs if you need to call to some OS function you added needed library and makes your call. One of the drawbacks where that now, your program is OS-depended, another problem was that your programs includes OS DLL in some fixed version. If another program on same station required that DLL in different version you were in trouble.
In the early days of the JVM history no JIT compiler where in used. So, your program run in interpreted mode. Your application has no longer needed to call OS directly, instead it use JVM for all it needs. JVM instead redirect some of the application calls to the OS. Think about JVM as mediator. One of the best features of the JVM where it's universality. You where not needed to stick to the specific OS (while in practice you do need to make some minor adjustments, when you are not stick to the Java requirement while your program "occasionally" works in some specific OS, for example you use C:\ for the files or assumptions upon Thread scheduler that is happen to be true on current OS, but generally JVM is not guaranteed to be true). Programmers of the JVM develop such API that can be easy in use for Java developer in one hand and it will be possible to map to any OS system calls on another hand.
JVM provides you more that simple wrapper to the OS. It has it's own memory model (thread synchronization) for example, that has some week grantees on it's own (it was totally revised in JDK 1.5, because it was broken). It also have garbage collection, it's initialize variables to null values (int i; i will be initialize to 0). That is JVM besides being moderator to OS is acting as helper code for your own application.
At some point JIT was added. It was added to reduce overhead that JVM creates. When some assumptions holds, usually after one execution of the code, command interpretation can be compiled to the machine code (I skip phase of byte code). It is optimization, and I don't know any case where you can effected.
In JDK 1.6 another optimization where added. Now, some objects in some circumstances can be allocated at the stack and not on the heap. I don't know, may be it has some side-effects, but it is example of what JVM can do for you.
And my last remark. When you compile your code, what really happens, your program is checked to be syntactically correct and then it byte-code generated (.class file). Java language use subset of the existing byte-codes (this is how AOP was implemented, using existing byte-codes that where not part of Java language). When java program is executed these byte codes are interpreted, they are translated on-the-fly to the machine instructions. If JIT is on, than some of the execution lines can be compiled to the machine language and reused instead of on-the-fly interpretation.

Since it is already machine codes, do we need the JVM any more?
compiled java programs are not the machine codes. [javac] compile [.java] file into bytecode [.class] file.Then these bytecodes are given to JRE [Java Run-time Environment].
Now the java interpreter comes in action that interpret the bytecode into native machine code that run on the CPU.

As we know OS does not Execute any program it provide Environment for processor to Execute if we talk about Environment it allocate Memory Loading file Giving instruction to the Processor,Manage the Address
of loaded data method work of the Processor is only Executing program this thing happen in c or any procedural programming Language if we see than OS Playing a very vital Role in this overhead on OS
Because if we write a small simple program in c like Hello World which contains only one Main function when will compile it generate .exe file of more than one function which is taken from Library function so manage all thing by OS is tedious job so in JVM has given Relief to OS here the work of OS is only to
load the JVM from hard disk to RAM and make the jvm Execute and allocate space for JVM to execute java Program here Momery allocation ,Loading on Byte code file from Hard disk,Address Management ,Memory Allocation and De-allocation is Done by JVM itself so OS is free it can do other work.jvm allocate or Deallocate memory based on What ever OS has given to Execute the java Program.
if we talk about Execution JVM Contains Interpreter as well as JIT compiler which converting the Byte code into Machine code of Required Function after Execution of the method Executable code of that method is destroyed thats why we can say java does have .EXE File

Java on mainframes

I work for a large corporation that runs a lot of x86 based servers on which we run JVMs.
We have experimented successfully with VMWare ESX to get better usage out of our data center. But these still consume a lot of power per processing unit.
I had a mad idea that we should resurrect mainframes, we could host either lots of JVMs or virtual machines.
Has anyone tried this? Are there any good cost-benefits?
Do you lose flexibility? E.g. we have mainframes in other parts of the company but they seem to have much more rigid usage of the machines.. lots of change control, long lead times etc

IBM makes a special Java co-processor that you should seriously consider. I would not run Java on the general engines as this may increase MPU charges for licensed software.

All this assumes you’re talking about Java on Z/OS and not running Linux VM’s on the mainframe to take advantage of the cost savings that come with fewer machines.
My thoughts on virtualization are at the end of this and it’s probably the route you want to look at but I’ll start out with Z/OS since it’s what mainframes are traditionally associated with and what I have familiarity with. I have some experience with mainframe Java.
The short answer is, it depends, but probably not. What exactly are your applications? The mainframe is a difficult environment compared to x86 servers. If you're running I/O-intensive workloads under something like Websphere, it might be worth it, assuming your mainframe is underutilized.
In my experience, Java is horribly slow on a mainframe but that’s because the system I used was set up for developer flexibility rather than performance. That just goes to prove performance tuning on the mainframe is usually much more complicated then on an average server since mainframes will be running many more workloads then a generic x86 server.
Remember that the mainframe is designed primarily for I/O throughput and can outperform any normal x86 server at that. It was not designed to do a lot of computationally intensive calculations so won’t outperform a small cluster of x86 servers if your doing a lot of math.
The change controls on mainframes are there for a good reason - if one x86 server has a problem, you reboot it. If a mainframe has a problem, every second that it’s down is costing the company money. You also have to take into account any native code your apps depend on or third party libraries that may use native code. All that code would have to be ported.
Configuration of a mainframe also takes a lot longer on average then on an x86 server. I would suggest that, if you want to seriously look into this, you make a better business case than power savings, such as tight integration with current business apps and start out small either with a proof of concept or a new application. One that is not business critical, that can be implemented to take advantage of the mainframes strengths.
IBM mainframes can also run Linux in either native mode or a virtualized environment similar to VMWare. Unless your company is the exception to the rule, your Linux instances would run as virtual machines. I haven’t had much experience with this but, if your app depends on no native code and runs under Linux, it would probably work on a mainframe running Linux. For more info about Linux on mainframes see this link.

We have extensive experience running Java under Windows, Linux and on IBM SystemI (or iSeries, or AS/400, depending on IBM's mood that year) minicomputers. It is my opinion that the mini-computer platform seems to deliver much less bang for your buck against modern multi-core x86 CPU's.
Note that Java benefits more readily from having multiple cores available than typical software today, because of it's inherently multithreaded nature - this would be even more true as you run multiple JVMs.
That said, you will typically be capable of getting many more CPU cores available with better bandwidth to access memory on a mini or mainframe, and better throughput on disk subsystems (overall) so these systems may very well scale much better as you toss more JVMs on them.

IBM allows this. Some of their mainframes can hold Java accelerator processors that run the bytecode natively for more performance. They also have DB2 accelerators, and possibly some for XML operations.
I've never gotten to play with any of them, but I'd sure love to.

Though I've been in the Industry since 1975, I'm no longer sure what a "mainframe" is. My current development machine has four 3GHZ processors in it, 8GB of RAM, and 750GB of disk space (RAID 1, so it's really double that), and two 19-inch flatscreen monitors.
That's because I'm there on a contract. The employees all have much more powerful boxes than mine.
I understand that the server machines, especially the database servers, are much faster.
Mainframe?

Depending on you workload this is worth looking at!
There are a bewildering number of options available to you just using the IBM hardware:
Its definately worth considering the add on java processors.
(these are actually not that different form the standard cpus its just they are
restricted to java jvm workloads -- and -- most importantly are excluded from
cpu based software license pricing).
You can run multple Linux VMs each ruuning thier own Java app.
You can run multiple native VMs running thier minimalist operating system
used to be called DOS but they change the name every couple of years.
The software licenses are cheaper than the main OS, but it has very limited
functionality which turns out to be an advantage if you are running self contained
applications.
You can run in the monster z/OS environment either:-
a. Within USS (Unix System Services) which is pretty much a full UNIX
OS running inside the parent z/OS.
b. Run your java app in its own started task (== unix daemon).
c. Run your app inside CICS.
(Probably not as you need to use CICS/Java API where you would
normally use Servlet/J2EE APIs so you app would require a rewrite.)