By reading this article, I know that each java application will run in a specific Java Virtual Machine Instance. So if I execute the following commands("Java -jar test1.jar","Java -jar test2.jar", I will get two processes in the system. And If each command used the default heap size, for example, 256M. The total memory cost is 512M, is that right?
Also I have other questions:
Is the Java virtual Machine a daemon process, start up with the system?
When I execute "java -jar test1.jar", it will create an instance of Java Virtual Machine, then execute the main function. Does it mean every running java application is a sub thread or process of Java Virtual Machine?
Is each running java application individual, other application can not get variable, method, constant, etc, from this running java application?
If one running java application is crashed, will it affect other running java application?
PS: I googled and got lots of different answers, I was totally confused. Anyone who can help me on this kind of questions or even more depth of Java virtual Machine. For example, How it works.
The JVM is a standard process, just like any other. As such there's no implicit communication or state sharing between the two. Each will have their own heap, threads etc. If you kill one it won't affect the other.
What will get shared are the code pages of the JVM itself. The kernel is intelligent enough to identify the same binary (any binary -not just the JVM) running twice and reuse the image. This only applies to the actual binary code - not its state. See here for more info re. Linux.
The JVM isn't a daemon process, but could be started upon system startup as a Windows service or Unix/Linux process (via /etc/init.d scripts). This is how you'd (say) run a web service written in Java when a machine is booted up.
1) No, but there a ways to launch java applications as services with wrappers (Google for "Java service").
2) Yes.
3) You can use communication between processes (v.g. HTTP). But there are no shortcuts due to all processes being run in JVM.
4) No
For the OS, JVM like an user application. Each JVM Instance is individual.
No. JVM is normal process as others.But you can run it as deamon process.
Yes. Java application run on JVM just like you application on OS.
Yes. Each JVM thread is individual, but they can communication whith other JVMs through network,RMI...
It depends. Normally they are individual, but if a JVM crash cause the OS crash, other JVMs will be effected.
Related
From Java In a Nutshell
jps provides a list of all active JVM processes on the local machine (or a remote machine, if a suitable instance of jstatd is running on the remote side).
What does "JVM processes" here mean,
processes of the underlying OS which run JVM exactly, or
processes that are supported by Java via Process, ProcessBuilder and Runtime.exec()...
Thanks.
A running Java Virtual Machine (JVM) instance is materialized by a native process launched by an OS while a Process class instance is a native process launched by a running JVM.
As each Java Virtual Machine is associated to a specific native process, instead of saying a process that runs a JVM, we could so shortcut it by a JVM process.
JVM stands for Java Virtual Machine.
In plain English, a virtual machine (VM) is any piece of software that simulates a real machine. There are two kinds of VMs:
system VM
process VM
A system virtual machine provides the functionality of a real computer. A process virtual machines allows to execute programs in one specific programming language. The advantage of a process VM (sometimes also called managed runtime environment) is that it provides the same environment across different platforms.
JVM is the process virtual machine for Java.
Since of the main design goals of Java is portability, the Java language code gets compiled to an intermediate representation called Java bytecode that can be executed on a JVM.
So, basically every time you run Java code you start an own JVM process.
Image source: Introduction to Computer Science using Java
There are exceptions to that, namely special-purpose processors that can interpret Java bytecode: with such processors Java is executed directly on the hardware without using a virtual machine. An example are ARM processors endowed with the Jazelle DBX direct bytecode execution.
I am a java beginner. i just read a line "
JVM (Java Virtual Machine) is an abstract machine." can anyone please help me to understand term abstract machine. what is abstract machine.
JVM = JAVA VIRTUAL MACHINE:- The word virtual itself indicates that it doesn't exists PHYSICALLY.
Elaborated here:
Abstract means HIDDEN.
When assembly programs runs on a computer, it is executed in the system runtime environment:
Properties
Platform dependent (if compiled for windows, a program will run only in windows not in Linux/UNIX etc.)
Not portable (same as above)
Systems runtime (in user's PC mainly under OS's control)
When Java Program runs into a computer, it is executed in another virtual machine (JVM) for which, the runtime environment is provided by JRE (JAVA Runtime Environment), it is installed automatically when you install JDK (Java Development Kit).
Without JRE, it is impossible to run Java Programs (Update: You can bundle your custom JRE with your code, in that case no need to install JDK or JRE separately but only in JDK9 & above)
This JVM itself runs in the system runtime (in user's PC/OS) but when Java program runs it is loaded into this running JVM.
For more practical AND visual experience:(for Windows only)
Open Task Manager
Go to Processes Tab
Find Java(TM) Platform SE Binary (This is JVM) - Java Instance
And now run a java program and write some code to delay the execution, like multi-threading with wait and notify (you can find such programs on google), due to this running program your Java Instance will show a little high memory and disk usage (not much high but slightly higher than that when no program was running in JRE/JVM). These processes you see in Task Manager, are running in System Runtime, and your Java program will not be listed there.
Instead it will be running inside this already running JRE.
This is the reason why JVM is ABSTRACT.
Now, do a little cross check and prove it..
Run 2-3 java programs, either keep them in longer waiting or just write Input Scanner and don't provide input, program will continue to run in blocking state so that we can see them later.
Once gain, confirm that only one instance of JVM/Java is running in task manager (Depends on how many JREs you have installed, sometimes IDEs can also create one instance, so better close it first for clear observation)
Now, where are those 2-3 Java Programs running?? Open VisualVM (it's under the same package/folder where your java executable resides)..
In this VisualVM, you can clearly see that, all your RUNNING Java Programs are listed.
Now, open side by side windows... Task Manager, VisualVM and one of your Running Code's Console.
Verify,
in Task manager - 1 instance of Java Binary.
in VisualVM - 3 different instances of your programs (if you run 3 java porgram)
Now, provide input in one of your code so that blocking state goes away and program terminates successfully.
Now verify,
in Task Manager - still 1 instance of Java Binary.
in VisualVM - 2 instances, because 1 code terminated/finished.
So, all your Java programs run under a Virtual Machine, a machine that is hidden, physically not available, abstract.
An abstract machine is a machine that does not have a physical existence.
Abstractness
A bicycle has a physical existence. I can touch it. It is not abstract.
A computer chip has a physical existence. I can touch it. It is not abstract.
A JVM is an executing program ... and has no physical existence. I cannot touch it. It is abstract.
Machine-ness:
A bicycle is a machine for transporting people.
A computer chip is a machine for executing programs that are coded in the instruction set of the chip; e.g. Intel x86 machine code.
A JVM is also a machine for executing programs that are coded in the instruction set of all JVMs; i.e. Java bytecodes.
Abstract machine means all of java application run in JVM and JVM runs in different platform as Window, Linux, Mac ...
JVM is interface to java application can run all platform
It is a bit philosophical question. When java application is compiled, the compiler produces its own "assembly" code that can not run directly on a hardware, it needs JVM. So, JVM creates an environment for java code similar to that of a machine. In other words from java perspective it is a machine, but in reality is a program that sits on top of a computer's operating system.
It means not real machine, however, it acts like a machine. Not any machine but as a machine called Central Processing Unit(CPU).
You could understand this like, whenever you write java program, you are writing instructions for a machine, but this machine is abstract, which is called Java Virtual Machine(JVM).
For each Operating system(OS) there is a Virtual Machine so that you do not have to write different versions of your java program to different OS.The JVM that you have in your JDK will handle the translation to each OS.
Your java program passes these steps to be understood by the underlying OS.
.java (Source file) gets compiled by compiler and becomes .class(class file) and this will be passed to JVM to be interpreted to machine language.
Class file is the one that has instructions for JVM
They could be many JVMs per Operative system or it is only one JVM per Operative System ? I also read that with "Runtime.exit()", we stop the execution of a JVM?
I'm a bit confuse because I've always thought that JVM is a machine that never stop working, always awaken waiting to be called for example by the "java App.class".
The JVM is an abstract concept, and there may be many running instances per Operating System. The implementation is usually through the Java Runtime Environment. And when exit is called, the runtime stops. The JVM can certainly stop. And (on most computers) it has to be explicitly started.
i'have always thougth that JVM is a machine that never stop working, always awaken waiting to be called for example by the "java App.class"
No, that is not how the JVM works. It's not a background process that is waiting to execute your Java programs. There is not always just one JVM running on one computer.
Whenever you start a Java program, a new JVM is started. When you have multiple Java programs running at the same time, you have multiple JVMs running. Each program is running in its own JVM.
System.exit() stops the JVM that is running the current Java application. It has no effect on other Java programs running on the same machine.
If you start a java app (directly or indirectly with the java shell command), then an instance of the JVM is created and started.
When the application finishes (either by reaching the end or through System.exit() then the JVM instance stops.
Of course, you can have multiple Java apps running simultaneously. Each will be in its own JVM instance.
They could be many JVMs per Operative system or it is only one JVM per Operative System ?
You can do either. You can run a JVM for each command, or you can use an application server to run your java applications. (You cna have more than one application server)
I also read that with "Runtime.exit()", we stop the execution of a JVM ?
This triggers the JVM to shutdown. The process does some work such as calling Shutdown Hooks after this is called.
i' m a bit confuse because i'have always thougth that JVM is a machine that never stop working,
It can be used that way. For example scala has a daemon compiler which is used to compile scala programs.
always awaken waiting to be called for example by the "java App.class".
When you run any program, (java or not) this always starts a new program. The only time this doesn't happen is for built in shell commands. e.g. set
Is Java Virtual Machine starts before user logged in or it's start after boot windows.?
Every time you start a java program, a new instance of the Java Virtual machine is started. It stops when the program ends.
In the case of a java applet, the browser will invoke the virtual machine itself.
When a Java application starts, a runtime jvm instance is born. When the application completes, the instance dies. If you start four Java applications at the same time, on the same computer, using the same concrete implementation, you'll get four Java virtual machine instances. Each Java application runs inside its own Java virtual machine.
JVM starts when it's required, in other words as soon as you need an environment to run your Java code, meaning when you start your application.
Try googling for "when JVM starts", it should yield a lot of results which address this question (in Java and also for other languages using JVM). For example this page. Look for "The lifetime of a Java Virtual Machine".
In Windows "Java Virtual Machine" is simply "java.exe" executable.
It will start whey you will start it - manually, by putting it to autorun or by creating Windows Service.
It is the same as any other background application.
I currently work in a Weblogic Java EE project, where from time to time the application executes a Perl script to do some batch jobs. In the application the script is getting invoked as
Process p = Runtime.getRuntime().exec(cmdString);
Though it is a dangerous way to run, but it was working properly until we had a requirement to execute the script synchronously under a for loop. After a couple of run we are getting
java.io.IOException: Not enough space as probably OS is running out of virtual memory while exec-ing under a for loop. As a result we are not able to run the script at all in the server.
I am desperately looking for a safer and better way to run the Perl script, where we don't need to fork the parent process, or at-least not to eat-up all swap space!
The spec is as follows:
Appserver - Weblogic 9.52
JDK - 1.5
OS - SunOS 5.10
Sun-Fire-T200
I've had something similar on a couple of occasions. Since the child process is a fork of the (very large parent it can see all of it shares all it's memory (using copy on write). What i discovered was that the kernel needs to be able to ensure that it could copy all of the memory pages before forking the child, on a 32bit OS you run out of virtual head run really fast.
Possible solutions:
Use a 64Bit OS and JVM, pushes the issue down the road so far it doesn't matter
Host your script in another process (like HTTPD) and poke it using a HTTP request to invoke it
Create a perl-server, which reads perl scripts via network and executes them one by one.
If you want to keep your code unchanged and have enough disk free space, you can just add a sufficiently large swap area to your OS.
Assuming you need 10 GB, here is how you do it with UFS:
mkfile 10g /export/home/10g-swap
swap -a /export/home/10g-swap
echo "/export/home/10g-swap - - swap - no -" >> /etc/vfstab
If you use ZFS, that would be:
zfs create -V 10gb rpool/swap1
swap -a /dev/zvol/dsk/rpool/swap1
Don't worry about that large a swap, this won't have any performance impact as the swap will only be used for virtual memory reservation, not pagination.
Otherwise, as already suggested in previous replies, one way to avoid the virtual memory issue you experience would be to use a helper program, i.e. a small service that your contact through a network socket (or a higher level protocol like ssh) and that executes the perl script "remotely".
Note that the issue has nothing to do with a 32-bit or 64-bit JVM, it is just Solaris doesn't overcommit memory and this is by design.