Content deleted Content added
Tag: Reverted |
m Reverted 1 edit by 2405:9800:B860:9CC2:5141:1018:8F23:6F79 (talk) to last revision by Xose.vazquez |
||
| (48 intermediate revisions by 10 users not shown) | |||
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 [[Load–store architecture|register–register]]
Line 30:
{{Blockquote|[[Sun Microsystems|We]] intend that this specification should sufficiently document the Java Virtual Machine to make possible compatible clean-room implementations. Oracle provides tests that verify the proper operation of implementations of the Java Virtual Machine.}}
The most commonly used Java virtual machine is Oracle's [[HotSpot (virtual machine)|HotSpot]].
One of Oracle's JVMs is named HotSpot; the other, inherited from [[BEA Systems]], is [[JRockit]]. 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===
Line 49 ⟶ 83:
Every Java virtual machine implementation must have a bootstrap class loader that is capable of loading trusted classes, as well as an extension class loader or application class loader. The Java virtual machine specification does not specify how a class loader should locate classes.
===Virtual
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 types ([[integer]]s, Floating-point, long etc.) and Reference types. The earlier JVM were only [[32-bit computing|32-bit]] machines. <code>long</code> and <code>double</code> types, which are [[64-bit computing|64-bits]], are supported natively, but consume two units of storage in a frame's local variables or operand stack, since each unit is 32 bits. <code>boolean</code>, <code>byte</code>, <code>short</code>, and <code>char</code> types are all [[sign-extended]] (except <code>char</code> which is [[Sign extension#zero-extended|zero-extended]]) and operated on as 32-bit integers, the same as <code>int</code> types. The smaller types only have a few type-specific instructions for loading, storing, and type conversion. <code>boolean</code> is operated on as 8-bit <code>byte</code> values, with 0 representing <code>false</code> and 1 representing <code>true</code>. (Although <code>boolean</code> has been treated as a type since ''The Java Virtual Machine Specification, Second Edition'' clarified this issue, in compiled and executed code there is little difference between a <code>boolean</code> and a <code>byte</code> except for [[Name mangling#Java|name mangling]] in [[method signature]]s and the type of boolean arrays. <code>boolean</code>s in method signatures are mangled as <code>Z</code> while <code>byte</code>s are mangled as <code>B</code>. Boolean arrays carry the type <code>boolean[]</code> but use 8 bits per element, and the JVM has no built-in capability to pack booleans into a [[bit array]], so except for the type they perform and behave the same as <code>byte</code> arrays. In all other uses, the <code>boolean</code> type is effectively unknown to the JVM as all instructions to operate on booleans are also used to operate on <code>byte</code>s.) However
The JVM has a garbage-collected heap for storing objects and arrays. Code, constants, and other class data are stored in the "method area". The method area is logically part of the heap, but implementations may treat the method area separately from the heap, and for example might not garbage collect it. Each JVM thread also has its own [[call stack]] (called a "Java Virtual Machine stack" for clarity), which stores [[Call stack#STACK-FRAME|frames]]. A new frame is created each time a method is called, and the frame is destroyed when that method exits.
| |||