`
fantasy
  • 浏览: 516057 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

JVM运行时数据区(2011年6月的JVM规范)

    博客分类:
  • Java
 
阅读更多

本文是《The Java Virtual Machine Specification Java SE 7 Edition)》运行时区的翻译,原文参见:http://download.oracle.com/javase/7/specs/jvms/JVMS-JavaSE7.pdf

 

JVM定义了若干个程序执行期间使用的数据区域。这个区域里的一些数据在JVM启动的时候创建,在JVM退出的时候销毁。其他的数据依赖于每一个线程,在线程创建的时候创建,在线程退出的时候销毁。

 

2.5.1  程序计数器(The pc Register

JVM一次能支持很多线程执行。每一个JVM线程有它自己的程序计数器。在任何时候,一个JVM的线程都正在执行当前线程的方法代码。如果这个方法不是本地方法,程序计数器包含当前被执行的JVM地址。如果线程正在执行本地方法,程序计数器的值为未定义。JVM 程序计数器足以存储一个返回地址或一个本地指针。

 

2.5.2  栈(Java Virtual Machine Stacks

每个JVM的线程在创建的时候,都会创建一个栈。一个栈包含很多栈桢。JVM的栈好比传统语言C的栈,它维持(存储)本地变量和部分结果,并在方法调用和返回中()使用。由于JVM栈除了压入和弹出栈帧之外不能被直接操作,栈帧可以在堆上分配空间。 JVM说明书(规范)允许栈要么是一个固定大小,要么动态扩展来满足计算的要求。如果JVM栈是一个固定的大小,当栈被创建的时候每一个栈大小可以自由设置。 在动态扩展情况下,可以控制最大最小内存。 VM Spec中对这个区域规定了2种异常状况(以下两种异常与JVM的栈机制有关)

l  如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常。

l  如果VM栈可以动态扩展,在初始化新线程时没有足够内存创建栈则抛出OutOfMemoryError异常。

 

2.5.3  堆(Heap

JVM有一个在所有线程内共享的堆。堆是给所有类的实例和数组分配内存的运行时数据区。 堆在虚拟机启动的时候创建,堆中储存的对象通过一个自动存储管理系统(垃圾回收器)进行回收。 对象从不明确的被分配(JVM从不指明对象的释放)JVM加上没有(JVM不指定特定的自动存储管理系统)自动存储管理系统的特别的类型,(开发者可根据系统要求自主选择)并且这个存储管理技术可能被选择按照实现的系统需求。

堆要么是固定大小,要么按计算需要扩展。如果一个大的堆变得多余或许会收缩。堆的内存不需要相邻。使用者可以设置堆内存的大小,如果堆能够动态的扩展。控制最大最小堆内存。

堆会出现以下异常:

l  如果内存溢出(若计算所需堆内存不足),则抛出OutOfMemoryError

 

2.5.4 方法区(Method Area

JVM的方法区是所有线程共享的,方法区类似于传统语言编译代码时的存储区域或类似于操作系统进程的文本段。他存储内容包括:每一个类的结构,如运行时常量池,字段和方法的数据;方法和构造器的代码,如用于类,实例和接口初始化的特殊方法。这个方法区在JVM启动的时候被创建,一般情况下JVM不会选择对方法区进行垃圾回收或者压缩,这个版本的JVM规范没有强制规定方法区的位置和管理编译后代码的策略。方法区可固定大小,或按需伸缩。方法区的内存不需要相邻。

 

2.5.4 运行时常量池(Runtime Constant Pool)

运行时常量池是类和接口运行时的常量池表,它在字节码文件里。它包含几类常量。 在编译时期识别的数值常量,在运行区识别的方法或引用字段。运行区常量池类似于传统语言的字符表,但它比传统字符表所存储的范围更广。每一个运行区常量池从方法区分配内存。当类和接口被JVM创建时相应的常量池也被创建。
      
运行区常量池包括以下异常:

l  当类和接口创建时,如果运行区常量池所需内存不足,则抛出OutOfMemoryError

 

2.5.5 本地方法栈(Native Method Stacks)

JVM一般用传统栈实现,俗称“C栈”用来支持本地方法(这些方法不是用java编程语言写的方法)。本地方法栈还可以被用于翻译C语言所编写的JVM指令集。那些不加载本地方法,不依赖于传统栈所实现的JVM不需要提供本地方法栈。如果提供本地方法栈,每个线程创建时必须分配一个本地方法栈。JVM规范规定本地方法栈可固定长度或按需伸缩。 如果JVM栈是一个固定的大小,当栈被创建的时候每一个栈大小可以自由设置。 在动态扩展情况下,可以控制最大最小内存。

JVM的方法栈有以下两种异常:

l  如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常。

l  如果VM栈可以动态扩展,当扩展时无法申请到足够内存(或者在初始化新线程时没有足够内存创建栈)则抛出OutOfMemoryError异常。

 

----------------------------------------------------原文------------------------------------------------------------

 

2.5.1 The pc Register

The Java virtual machine can support many threads of execution at once .

Each Java virtual machine thread has its own pc (program counter) register. At any

point, each Java virtual machine thread is executing the code of a single method,

namely the current method (§2.6) for that thread. If that method is not native, the

pc register contains the address of the Java virtual machine instruction currently

being executed. If the method currently being executed by the thread is native, the

value of the Java virtual machine’s pc register is undefined. The Java virtual

machine’s pc register is wide enough to hold a returnAddress or a native pointer

on the specific platform.

 

2.5.2 Java Virtual Machine Stacks

Each Java virtual machine thread has a private Java virtual machine stack, created

at the same time as the thread.3 A Java virtual machine stack stores frames (§2.6). A

Java virtual machine stack is analogous to the stack of a conventional language such

as C: it holds local variables and partial results, and plays a part in method invocation

and return. Because the Java virtual machine stack is never manipulated

directly except to push and pop frames, frames may be heap allocated. The memory

for a Java virtual machine stack does not need to be contiguous.

The Java virtual machine specification permits Java virtual machine stacks

either to be of a fixed size or to dynamically expand and contract as required by

the computation. If the Java virtual machine stacks are of a fixed size, the size of

each Java virtual machine stack may be chosen independently when that stack is

created. A Java virtual machine implementation may provide the programmer or

the user control over the initial size of Java virtual machine stacks, as well as, in

the case of dynamically expanding or contracting Java virtual machine stacks,

control over the maximum and minimum sizes.

The following exceptional conditions are associated with Java virtual

machine stacks:

l  If the computation in a thread requires a larger Java virtual machine stack than

is permitted, the Java virtual machine throws a StackOverflowError.

l  If Java virtual machine stacks can be dynamically expanded, and expansion is

attempted but insufficient memory can be made available to effect the expansion,

or if insufficient memory can be made available to create the initial Java

virtual machine stack for a new thread, the Java virtual machine throws an

OutOfMemoryError.

 

2.5.3 Heap

The Java virtual machine has a heap that is shared among all Java virtual machine

threads. The heap is the runtime data area from which memory for all class instances

and arrays is allocated.

The heap is created on virtual machine start-up. Heap storage for objects is

reclaimed by an automatic storage management system (known as a garbage collector);

objects are never explicitly deallocated. The Java virtual machine assumes

no particular type of automatic storage management system, and the storage management

technique may be chosen according to the implementor’s system requirements.

The heap may be of a fixed size or may be expanded as required by the

computation and may be contracted if a larger heap becomes unnecessary. The

memory for the heap does not need to be contiguous.

A Java virtual machine implementation may provide the programmer or the

user control over the initial size of the heap, as well as, if the heap can be dynamically

expanded or contracted, control over the maximum and minimum heap size.

The following exceptional condition is associated with the heap:

• If a computation requires more heap than can be made available by the automatic

storage management system, the Java virtual machine throws an Out-

OfMemoryError.

 

2.5.4 Method Area

The Java virtual machine has a method area that is shared among all Java virtual

machine threads. The method area is analogous to the storage area for compiled

code of a conventional language or analogous to the “text” segment in an operating

system process. It stores per-class structures such as the runtime constant pool, field

and method data, and the code for methods and constructors, including the special

methods (§2.9) used in class and instance initialization and interface initialization.

The method area is created on virtual machine start-up. Although the method

area is logically part of the heap, simple implementations may choose not to either

garbage collect or compact it. This version of the Java virtual machine specification

does not mandate the location of the method area or the policies used to manage

compiled code. The method area may be of a fixed size or may be expanded

as required by the computation and may be contracted if a larger method area

becomes unnecessary. The memory for the method area does not need to be contiguous.

A Java virtual machine implementation may provide the programmer or the

user control over the initial size of the method area, as well as, in the case of a varying-

size method area, control over the maximum and minimum method area size.

The following exceptional condition is associated with the method area:

• If memory in the method area cannot be made available to satisfy an allocation

request, the Java virtual machine throws an OutOfMemoryError.

 

2.5.5 Runtime Constant Pool

A runtime constant pool is a per-class or per-interface runtime representation of the

constant_pool table in a class file (§4.4). It contains several kinds of constants,

ranging from numeric literals known at compile time to method and field references

that must be resolved at runtime. The runtime constant pool serves a function similar

to that of a symbol table for a conventional programming language, although it

contains a wider range of data than a typical symbol table.

Each runtime constant pool is allocated from the Java virtual machine’s

method area (§2.5.4). The runtime constant pool for a class or interface is constructed

when the class or interface is created (§5.3) by the Java virtual machine.

The following exceptional condition is associated with the construction of the

runtime constant pool for a class or interface:

• When creating a class or interface, if the construction of the runtime constant

pool requires more memory than can be made available in the method area of

the Java virtual machine, the Java virtual machine throws an OutOfMemory-

Error.

See Chapter 5, “Loading, Linking, and Initializing,” for information about the

construction of the runtime constant pool.

2.5.6 Native Method Stacks

An implementation of the Java virtual machine may use conventional stacks, colloquially

called “C stacks,” to support native methods, methods written in a language

other than the Java programming language. Native method stacks may also be

used by the implementation of an interpreter for the Java virtual machine’s instruction

set in a language such as C. Java virtual machine implementations that cannot

load native methods and that do not themselves rely on conventional stacks need

not supply native method stacks. If supplied, native method stacks are typically allocated

per thread when each thread is created.

The Java virtual machine specification permits native method stacks either to

be of a fixed size or to dynamically expand and contract as required by the computation.

If the native method stacks are of a fixed size, the size of each native

method stack may be chosen independently when that stack is created. In any

case, a Java virtual machine implementation may provide the programmer or the

user control over the initial size of the native method stacks. In the case of

varying-size native method stacks, it may also make available control over the

maximum and minimum method stack sizes.

The following exceptional conditions are associated with native method

stacks:

• If the computation in a thread requires a larger native method stack than is

permitted, the Java virtual machine throws a StackOverflowError.

• If native method stacks can be dynamically expanded and native method stack

expansion is attempted but insufficient memory can be made available, or if

insufficient memory can be made available to create the initial native method

stack for a new thread, the Java virtual machine throws an OutOfMemory-

Error.

  • 大小: 47.2 KB
分享到:
评论
1 楼 rubyeye 2012-02-14  
非常好,希望能多翻译些java规范,受益了

相关推荐

    Java虚拟机规范(英文)

    6. 规范的作用:JVM规范作为Java平台的基础性文档,规定了JVM的内部架构、数据类型、指令集、运行时数据区、垃圾收集机制等核心内容,是Java开发者和虚拟机实现者必须遵循的标准。 综合以上内容,我们可以看到...

    Java虚拟机规范(Java SE 7 中文版)

    尽管JDK 5的发布带来了重大更新,但完整的新版规范直至2011年7月才正式发布。这一版规范不仅反映了Java技术的最新发展,还适应了高性能虚拟机的需求,修正了与早期Sun虚拟机实现之间的差异,强调了规范作为概念模型...

    The Java Virtual Machine Specification Java SE 7 Edition

    该规范由Tim Lindholm、Frank Yellin、Gilad Bracha和Alex Buckley等人编写,并于2011年7月发布。 #### 二、JVM规范的重要内容 1. **类文件格式**:规范定义了Java类文件的格式,包括类、接口、字段、方法、属性等...

    Java虚拟机规范 SE7

    自1999年第二版发布以来,历经十余年,《Java虚拟机规范》在2011年7月迎来了针对Java SE7的重大更新,标志着JVM发展的重要里程碑。 #### 二、重要性 ##### 1. 统一性与兼容性 《Java虚拟机规范》作为一份契约文档...

    Java虚拟机特性JAVA SE 7.pdf-中文完整书签文字版

    本书涵盖了JVM的基本概念、数据类型、运行时数据区、指令集等核心内容,并提供了详细的规范说明。 #### 核心知识点 **1. Java虚拟机简介** - **历史背景**: Java虚拟机的历史可追溯至1995年,随着Java语言的诞生...

    Java虚拟机规范(Java+SE+7)

    - **核心组件**:包括类文件格式、运行时数据区、执行引擎、异常处理、垃圾回收器等方面的具体规定。 - **兼容性与一致性**:详细说明了如何确保Java程序在不同Java虚拟机上的兼容性和一致性。 #### 五、Java虚拟机...

    Java虚拟机规范 J2SE_7 中文版

    该文档首次正式发布于2011年7月28日,由三位译者周志明(IcyFenix)、吴璞渊(wupuyuan)和冶秀刚(langyu)合作翻译成中文,并于同年11月13日完成。 #### 二、翻译背景与目的 该文档的中文翻译工作始于2011年初,...

    Java虚拟机规范(中文版) Java SE 7

    该文档的原文版本发布于2011年7月28日,中文版则由周志明、吴璞渊和冶秀刚三位译者共同翻译完成,最终版本于2011年11月13日发布。这份中文版文档共计387页,全面涵盖了Java SE 7虚拟机的核心内容。 #### 译者介绍 ...

Global site tag (gtag.js) - Google Analytics