Content deleted Content added
Tag: references removed |
m Reverted 1 edit by 2405:9800:B860:9CC2:5141:1018:8F23:6F79 (talk) to last revision by Xose.vazquez |
||
| (192 intermediate revisions by more than 100 users not shown) | |||
Line 1:
{{Redirect|JVM}}
▲{{short description|Virtual machine}}
{{Infobox CPU architecture
| name = Java virtual machine
Line 6:
| bits = [[32-bit computing|32-bit]]
| introduced = 1994
| version = {{wikidata|property|preferred|references|edit|Q251|P348|P548=Q2804309}}
| design =
| type = [[Stack machine|Stack]] and [[
| encoding = Variable
| branching = Compare and branch
Line 20:
}}
[[File:JvmSpec7.png|thumb|Overview of a Java virtual machine (JVM) architecture based on The Java Virtual Machine Specification Java SE 7 Edition]]
A '''Java virtual machine''' ('''JVM''') is a [[virtual machine]] that enables a computer to run [[Java (software platform)|Java]] programs as well as programs written in [[List of JVM languages|other languages]] that are also compiled to [[Java bytecode]].
The JVM [[reference implementation]] is developed by the [[OpenJDK]] project as [[Open-source software|open source]] code and includes a [[JIT compiler]] called [[HotSpot (virtual machine)|HotSpot]].
==JVM specification==
The Java virtual machine is an abstract (virtual) computer defined by a specification. It is a part of the Java runtime environment. The [[Garbage collection (computer science)|garbage
Starting with [[Java Platform, Standard Edition]] (J2SE) 5.0, changes to the JVM specification have been developed under the [[Java Community Process]] as JSR 924.<ref>{{cite web |url=http://www.jcp.org/en/jsr/detail?id=924 |title=The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 924 |publisher=Jcp.org |access-date
{{
The most commonly used Java virtual machine is Oracle's [[HotSpot (virtual machine)|HotSpot]].
Oracle owns the Java trademark and may allow its use to certify implementation suites as fully compatible with Oracle's specification.
===Garbage collectors===
{{main|Garbage collection (computer science)#Java}}
{| class="wikitable"
|+ Java versions and their Garbage Collectors
|-
! Version !! Default GC !! Available GCs
|-
| 6u14 || rowspan="2" | Serial /<br />Parallel ([[Multiprocessor system architecture|MP]]) || Serial, Parallel, [[Concurrent mark sweep collector|CMS]], ''[[Garbage-first collector|G1]] (E)''
|-
| 7u4 - 8 || rowspan="2" | Serial, Parallel, CMS, G1
|-
| 9 - 10 || rowspan="9" | G1
|-
| 11 || Serial, Parallel, CMS, G1, ''Epsilon (E)'', ''ZGC (E)''
|-
| 12 - 13 || Serial, Parallel, CMS, G1, ''Epsilon (E)'', ''ZGC (E)'', ''Shenandoah (E)''
|-
| 14 || Serial, Parallel, G1, ''Epsilon (E)'', ''ZGC (E)'', ''Shenandoah (E)''
|-
| 15 - 20 || Serial, Parallel, G1, ''Epsilon (E)'', ZGC, Shenandoah
|-
| 21 - 22 || Serial, Parallel, G1, ''Epsilon (E)'', ZGC, Shenandoah, ''GenZGC (E)''
|-
| 23 || Serial, Parallel, G1, ''Epsilon (E)'', ZGC, Shenandoah, GenZGC (default ZGC)
|-
| 24 || Serial, Parallel, G1, ''Epsilon (E)'', Shenandoah, GenZGC, ''GenShen (E)''
|-
| 25 || Serial, Parallel, G1, ''Epsilon (E)'', Shenandoah, GenZGC, GenShen
|-
| colspan="3" | <small> ''(E)'' = ''experimental''</small>
|}
===Class loader===
{{Main|Java
One of the organizational units of JVM byte code is a [[Class (computer programming)|class]]. A class loader implementation must be able to recognize and load anything that conforms to the Java class [[file format]]. Any implementation is free to recognize other binary forms besides ''class'' files, but it must recognize ''class'' files.
The class loader performs three basic activities in this strict order:
Line 45 ⟶ 79:
#Initialization: invokes Java code that initializes class variables to their proper starting values.
In general, there are
Every Java virtual machine implementation must have a bootstrap class loader
===Virtual machine architecture===
The JVM operates on specific types of data as specified in Java Virtual Machine specifications. The data types can be divided<ref>{{Cite web|url=https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.2|title=Chapter 2. The Structure of the Java Virtual Machine|access-date=2021-09-15|archive-date=2021-09-15|archive-url=https://web.archive.org/web/20210915050448/https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.2|url-status=live}}</ref> into primitive
The JVM has a
Each frame provides an "operand stack" and an array of "local variables". The operand stack is used for operands to run computations and for receiving the return value of a called method, while local variables serve the same purpose as [[Processor register|registers]] and are also used to pass method arguments. Thus, the JVM is both a [[stack machine]] and a [[register machine]]. In practice, HotSpot eliminates every stack besides the native thread/call stack even when running in Interpreted mode, as its Templating Interpreter technically functions as a compiler.
===Bytecode instructions===
Line 79 ⟶ 113:
===JVM languages===
{{Main|List of JVM languages}}
A JVM language is any language with functionality that can be expressed in terms of a valid class file which can be hosted by the Java Virtual Machine. A class file contains Java Virtual Machine instructions ([[Java byte code]]) and a symbol table, as well as other ancillary information. The class file format is the hardware- and operating system-independent binary format used to represent compiled classes and interfaces.<ref>{{cite web |url=http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf
There are several JVM languages, both old languages ported to JVM and completely new languages. [[JRuby]] and [[Jython]] are perhaps the most well-known ports of existing languages, i.e. [[Ruby (programming language)|Ruby]] and [[Python (programming language)|Python]] respectively. Of the new languages that have been created from scratch to compile to Java bytecode, [[Clojure]], [[Apache Groovy
Java 7 JVM implements ''JSR 292: Supporting Dynamically Typed Languages''<ref>{{cite web |url=https://jcp.org/en/jsr/detail?id=292 |title=The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 292 |publisher=Jcp.org |access-date
===Bytecode verifier===
Line 96 ⟶ 130:
The first two of these checks take place primarily during the verification step that occurs when a class is loaded and made eligible for use. The third is primarily performed dynamically, when data items or methods of a class are first accessed by another class.
The verifier permits only some bytecode sequences in valid programs, e.g. a [[branch (computer science)|jump (branch) instruction]] can only target an instruction within the same [[method (computer programming)|method]]. Furthermore, the verifier ensures that any given instruction operates on a fixed stack ___location,<ref>{{cite web |title=The Verification process |url=http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#9766 |work=The Java Virtual Machine Specification |publisher=Sun Microsystems |year=1999 |
The original specification for the bytecode verifier used natural language that was incomplete or incorrect in some respects. A number of attempts have been made to specify the JVM as a formal system. By doing this, the security of current JVM implementations can more thoroughly be analyzed, and potential security exploits prevented. It will also be possible to optimize the JVM by skipping unnecessary safety checks, if the application being run is proven to be safe.<ref>{{Cite book |doi=10.1145/320384.320397|chapter=A formal framework for the Java bytecode language and verifier|title=Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications - OOPSLA '99|pages=147–166|year=1999|last1=Freund|first1=Stephen N.|last2=Mitchell|first2=John C.|isbn=978-1581132380|citeseerx=10.1.1.2.4663|s2cid=14302964}}</ref>
====Secure execution of remote code====
A virtual machine architecture allows very fine-grained control over the actions that code within the machine is permitted to take. It assumes the code is "semantically" correct, that is, it successfully passed the (formal) bytecode verifier process, materialized by a tool, possibly off-board the virtual machine. This is designed to allow safe execution of untrusted code from remote sources, a model used by [[Java applet]]s, and other secure code downloads. Once bytecode-verified, the downloaded code runs in a restricted "[[sandbox (computer security)|sandbox]]", which is designed to protect the user from misbehaving or malicious code. As an addition to the bytecode verification process, publishers can purchase a certificate with which to [[digital signature|digitally sign]] applets as safe, giving them permission to ask the user to break out of the sandbox and access the local file system, [[clipboard (software)|clipboard]], execute external pieces of software, or network.
Formal proof of bytecode verifiers have been done by the Javacard industry (Formal Development of an Embedded Verifier for Java Card Byte Code<ref>{{cite web|last1=Casset|first1=Ludovic|last2=Burdy|first2=Lilian|last3=Requet|first3=Antoine|date=10 April 2002|title=Formal Development of an Embedded Verifier for Java Card Byte Code|website=Inria - National Institute for Research in Digital Science and Technology at [[Côte d'Azur University#National_research_organizations|Côte d'Azur University]]|url-status=live|archive-date=3 October 2022|url=http://www-sop.inria.fr/everest/Lilian.Burdy/CBR02dsn.pdf|archive-url=https://web.archive.org/web/20221003184410/http://www-sop.inria.fr/everest/Lilian.Burdy/CBR02dsn.pdf}}</ref>)
===Bytecode interpreter and just-in-time compiler===
For each [[hardware architecture]] a different Java bytecode [[Interpreter (computing)|interpreter]] is needed. When a computer has a Java bytecode interpreter, it can run any Java bytecode program, and the same program can be run on any computer that has such an interpreter.
When Java bytecode is executed by an interpreter, the execution will always be slower than the execution of the same program compiled into native machine language. This problem is mitigated by [[Just-in-time compilation|just-in-time (JIT) compilers]] for executing Java bytecode. A JIT compiler may translate Java bytecode into native machine language while executing the program. The translated parts of the program can then be executed much more quickly than they could be interpreted.
There is no necessary connection between the Java programming language and Java bytecode. A program written in Java can be compiled directly into the machine language of a real computer and programs written in other languages than Java can be compiled into Java bytecode.
Java bytecode is intended to be platform-independent and secure.<ref>David J. Eck, ''[http://math.hws.edu/javanotes/c1/s3.html Introduction to Programming Using Java] {{Webarchive|url=https://web.archive.org/web/20141011192544/http://math.hws.edu/javanotes/c1/s3.html |date=2014-10-11 }}'', Seventh Edition, Version 7.0, August 2014 at Section 1.3 "The Java Virtual Machine"</ref> Some JVM implementations do not include an interpreter, but consist only of a just-in-time compiler.<ref>''[http://docs.oracle.com/cd/E15289_01/doc.40/e15058/underst_jit.htm Oracle JRockit Introduction] {{Webarchive|url=https://web.archive.org/web/20150906145705/http://docs.oracle.com/cd/E15289_01/doc.40/e15058/underst_jit.htm |date=2015-09-06 }}'' Release R28 at 2. "Understanding Just-In-Time Compilation and Optimization"</ref>
==JVM in the web browser==
At the start of the Java platform's lifetime, the JVM was marketed as a web technology for creating [[Rich
The [[NPAPI]] Java browser plug-in was designed to allow the JVM to execute so-called [[Java applets]] embedded into HTML pages. For browsers with the plug-in installed, the applet is allowed to draw into a rectangular region on the page assigned to it. Because the plug-in includes a JVM, Java applets are not restricted to the Java programming language; any language targeting the JVM may run in the plug-in.
{{As of|June 2015}} according to W3Techs, Java applet and [[Microsoft Silverlight|Silverlight]] use had fallen to 0.1% each for all web sites, while Flash had fallen to 10.8%.<ref>{{cite web|url=http://w3techs.com/technologies/history_overview/client_side_language/all/y |title=Historical yearly trends in the usage of client-side programming languages, June 2015 |publisher=W3techs.com |access-date
===JavaScript JVMs and interpreters===
===
With the continuing improvements in JavaScript execution speed, combined with the increased use of mobile devices whose web browsers do not implement support for plugins, there are efforts to target those users through
Compiling the JVM bytecode, which is universal across JVM languages, allows building upon the language's existing compiler to bytecode. The main JVM bytecode to JavaScript
Leading
==See also==
{{Portal|Computer programming}}
* [[Common Language Runtime]]
* [[List of Java virtual machines]]
* [[List of JVM languages]]▼
* [[Comparison of Java virtual machines]]
* [[Comparison of application
* [[Automated exception handling]]
* [[Java performance]]
▲* [[List of JVM languages]]
* [[Java processor]]
* [[
==References==
Line 192 ⟶ 181:
{{Refbegin}}
* ''[http://java.sun.com/docs/books/vmspec/2nd-edition/jvms-clarify.html Clarifications and Amendments to the Java Virtual Machine Specification, Second Edition] {{Webarchive|url=https://web.archive.org/web/20060110040426/http://java.sun.com/docs/books/vmspec/2nd-edition/jvms-clarify.html |date=2006-01-10 }}'' includes list of changes to be made to support J2SE 5.0 and JSR 45
* [http://www.jcp.org/en/jsr/detail?id=45 JSR 45] {{Webarchive|url=https://web.archive.org/web/20060205094707/http://www.jcp.org/en/jsr/detail?id=45 |date=2006-02-05 }}, specifies changes to the class file format to support source-level debugging of languages such as [[JavaServer Pages]] (JSP) and [[SQLJ]] that are translated to Java
{{Refend}}
{{Java Virtual Machine}}
| |||