- 浏览: 3046507 次
- 性别:
- 来自: 海外
文章分类
- 全部博客 (430)
- Programming Languages (23)
- Compiler (20)
- Virtual Machine (57)
- Garbage Collection (4)
- HotSpot VM (26)
- Mono (2)
- SSCLI Rotor (1)
- Harmony (0)
- DLR (19)
- Ruby (28)
- C# (38)
- F# (3)
- Haskell (0)
- Scheme (1)
- Regular Expression (5)
- Python (4)
- ECMAScript (2)
- JavaScript (18)
- ActionScript (7)
- Squirrel (2)
- C (6)
- C++ (10)
- D (2)
- .NET (13)
- Java (86)
- Scala (1)
- Groovy (3)
- Optimization (6)
- Data Structure and Algorithm (3)
- Books (4)
- WPF (1)
- Game Engines (7)
- 吉里吉里 (12)
- UML (1)
- Reverse Engineering (11)
- NSIS (4)
- Utilities (3)
- Design Patterns (1)
- Visual Studio (9)
- Windows 7 (3)
- x86 Assembler (1)
- Android (2)
- School Assignment / Test (6)
- Anti-virus (1)
- REST (1)
- Profiling (1)
- misc (39)
- NetOA (12)
- rant (6)
- anime (5)
- Links (12)
- CLR (7)
- GC (1)
- OpenJDK (2)
- JVM (4)
- KVM (0)
- Rhino (1)
- LINQ (2)
- JScript (0)
- Nashorn (0)
- Dalvik (1)
- DTrace (0)
- LLVM (0)
- MSIL (0)
最新评论
-
mldxs:
虽然很多还是看不懂,写的很好!
虚拟机随谈(一):解释器,树遍历解释器,基于栈与基于寄存器,大杂烩 -
HanyuKing:
Java的多维数组 -
funnyone:
Java 8的default method与method resolution -
ljs_nogard:
Xamarin workbook - .Net Core 中不 ...
LINQ的恶搞…… -
txm119161336:
allocatestlye1 顺序为 // Fields o ...
最近做的两次Java/JVM分享的概要
在已经发布的Oracle JDK7 RC(JDK7 build 147)里,HotSpot VM仍然有PermGen,但许多原本存储在PermGen里的东西已经挪到了别的地方。
离HotSpot彻底移除PermGen的一天已经越来越近。本来PermGen就不是一个JVM完整不可分割的一部分,去了就去了呗。正好把许多同学们对PermGen的误解给扭过来
这草稿压箱底够久了,虽然还是乱七八糟的但还是先发出来吧,方便大家搜资料。
请重点关注JEP 122: Remove the Permanent Generation。这是移除PermGen的官方提案。
=========================================================================
Bug 6964458: Reimplement class meta-data storage to use native memory
=========================================================================
时间线
2010-01-27
Oracle终于得以正式收购Sun。在新闻发布会上,
Oracle + Sun: Transforming the IT Industry
Thomas Kurian做了题为“Software Strategy ”的主题演讲 (演示稿下载)
其中在5:00左右,他提到了关于Java SE的展望,
这里明确指出Oracle计划将HotSpot与JRockit合并为单一的高性能JVM,并准备移除前者中的“permanent generation”。
相关评论:
InfoQ: Perspectives on the Conclusion of the Oracle - Sun Acquisition
这则新闻里有Allex Miller对PermGen改进的评论:
2010-10-03
JavaOne 2010上,题为“Oracle's JVM Strategy”的演讲同样提到要将HotSpot与JRockit合并到一起,并透露了更多细节:以HotSpot为主,将JRockit一些优秀的部分移植到HotSpot中。其中,同样提到了要移除“permanent generation”。
Henrik Ståhl: Oracle's JVM Strategy (演示稿下载)
2010-11-03
QCon San Francisco 2010上,Adam Messinger演讲同样提到了这个话题
The Road Ahead for Java (演示稿下载)
2010-06-25
Bug ID 6964458: Reimplement class meta-data storage to use native memory
2010-10-08
Bug ID 6990754: Use native memory and reference counting to implement SymbolTable
2010-11-05
Request for review (XL) 6990754: Use native memory and reference counting to implement SymbolTable
http://bugs.sun.com/view_bug.do?bug_id=7019689 << 关联bug
http://bugs.sun.com/view_bug.do?bug_id=7019165 << 关联bug
Bug ID: 7019165
Votes 0
Synopsis Incorrect symbols in pstack output after SymbolTable changes
Category hotspot:runtime_system
Reported Against
Release Fixed hs21(b05), 7(b135) (Bug ID:2208133)
State 11-Closed, Unverified, bug
Priority: 3-Medium
Related Bugs 6990754
Submit Date 11-FEB-2011
2011-01-27
HotSpot要干掉PermGen了…
OpenJDK 7/HotSpot revision 3582bf76420e (changeset 2059): 6990754: Use native memory and reference counting to implement SymbolTable
第一个code push已经上OpenJDK 7了,
2011-02-10
JDK7 build 129
JDK7 build 129里的HotSpot 21已经开始移除PermGen,改为引用计数方式在native heap上管理SymbolTable
所以现在在HotSpot中的oop继承结构中,老的symbolOopDesc已经消失,取而代之的是新的Symbol类。
Jon Masamitsu在hotspot-dev邮件列表里提到JDK7发布前可能来不及完成将PermGen移除的工作
Bug ID 7017732: move static fields into Class to prepare for perm gen removal
经过这个修改后,java.lang.Class就变成HotSpot VM里的一个特例了:虽然它是Java对象(而不是数组),但它的大小却是可变的(像数组而不像普通对象)。
关联的一个bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7030435
Some oop_oop_iterate_m() methods iterate outside of specified memory bounds
Bug ID 6962931: move interned strings out of the perm gen
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7032129
<< 关联bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003421
8003421: NPG: Move oops out of InstanceKlass into mirror
=========================================================================
Java虚拟机规范第二版提到:3.5.4 Method Area
The Java HotSpot Performance Engine Architecture
HotSpot Runtime Overview
Storage Management
Troubleshooting Guide for Java SE 6 with HotSpot VM
我想说的在这个回帖里已经都说了:http://www.iteye.com/topic/1112592?page=2#2216243。没啥需要加的。
离HotSpot彻底移除PermGen的一天已经越来越近。本来PermGen就不是一个JVM完整不可分割的一部分,去了就去了呗。正好把许多同学们对PermGen的误解给扭过来
这草稿压箱底够久了,虽然还是乱七八糟的但还是先发出来吧,方便大家搜资料。
请重点关注JEP 122: Remove the Permanent Generation。这是移除PermGen的官方提案。
=========================================================================
Paul Hohensee 写道
Yes, the permgen is going away anyway.
Interned Strings and class static variables have been moved to the regular Java heap,
and Symbols into malloc'ed memory in hs21 (the current development version).
The rest of the metadata will go into per classloader+classes-it-loads arenas, one
per classloader. See allocation.* for arena implementation. You'll note that an
arena consists of fixed-sized malloc'ed chunks. The current plan is to dump these
into the CDS archive, though whether we'll make them relocatable or not is up in
the air. In theory, it should be possible to map the chunks at their old addresses
in a new process, because the space was available when the archive was created.
We might do what Linux does with shared libs, namely have a preferred address
and relocate if we can't get that address.
Interned Strings and class static variables have been moved to the regular Java heap,
and Symbols into malloc'ed memory in hs21 (the current development version).
The rest of the metadata will go into per classloader+classes-it-loads arenas, one
per classloader. See allocation.* for arena implementation. You'll note that an
arena consists of fixed-sized malloc'ed chunks. The current plan is to dump these
into the CDS archive, though whether we'll make them relocatable or not is up in
the air. In theory, it should be possible to map the chunks at their old addresses
in a new process, because the space was available when the archive was created.
We might do what Linux does with shared libs, namely have a preferred address
and relocate if we can't get that address.
Bug 6964458: Reimplement class meta-data storage to use native memory
=========================================================================
时间线
2010-01-27
Oracle终于得以正式收购Sun。在新闻发布会上,
Oracle + Sun: Transforming the IT Industry
Thomas Kurian做了题为“Software Strategy ”的主题演讲 (演示稿下载)
其中在5:00左右,他提到了关于Java SE的展望,
引用
·HotSpot and JRockit are strategic JVMs
- Converge best features of HotSpot and JRockit
- Management and Real-time Monitoring
- Run natively on Hypervisors
- Optimize/Remove Permgen
- Thread Local, Server Class Garbage Collection
- NUMA Compiler Optimization for Multi-Cores
- Converge best features of HotSpot and JRockit
- Management and Real-time Monitoring
- Run natively on Hypervisors
- Optimize/Remove Permgen
- Thread Local, Server Class Garbage Collection
- NUMA Compiler Optimization for Multi-Cores
这里明确指出Oracle计划将HotSpot与JRockit合并为单一的高性能JVM,并准备移除前者中的“permanent generation”。
相关评论:
InfoQ: Perspectives on the Conclusion of the Oracle - Sun Acquisition
这则新闻里有Allex Miller对PermGen改进的评论:
Allex Miller 写道
The permgen improvement is really needed to address a problem that has been getting worse with dynamic languages running on the JVM. Many of these languages like Groovy or JRuby dynamically generate large numbers of small classes at execution time to provide the dynamic behavior. These classes pollute the special "permgen" parts of Java memory and are difficult or impossible to reclaim, causing significant memory problems. The JSR 292 invokedynamic work is addressing some of this problem in another way by allowing dynamic languages to directly link call sites at runtime, avoiding the need to generate many of those internal classes at all.
2010-10-03
JavaOne 2010上,题为“Oracle's JVM Strategy”的演讲同样提到要将HotSpot与JRockit合并到一起,并透露了更多细节:以HotSpot为主,将JRockit一些优秀的部分移植到HotSpot中。其中,同样提到了要移除“permanent generation”。
Henrik Ståhl: Oracle's JVM Strategy (演示稿下载)
引用
·No artificial class metadata size limit
- App servers load or reload an unpredictable number of classes, often exceeding fixed size bounds
- Eliminate the Permanent Generation, move metadata to native memory
- Metadata size limited by virtual address space size
- App servers load or reload an unpredictable number of classes, often exceeding fixed size bounds
- Eliminate the Permanent Generation, move metadata to native memory
- Metadata size limited by virtual address space size
2010-11-03
QCon San Francisco 2010上,Adam Messinger演讲同样提到了这个话题
The Road Ahead for Java (演示稿下载)
2010-06-25
Bug ID 6964458: Reimplement class meta-data storage to use native memory
引用
Change the implementation of the storage for class meta-data in hotspot (klasses) to
use native memory.
Posted Date : 2010-06-25 22:50:22.0
use native memory.
Posted Date : 2010-06-25 22:50:22.0
2010-10-08
Bug ID 6990754: Use native memory and reference counting to implement SymbolTable
引用
As designed now, customers of Hotspot have to specify a fixed size for the permanent generation, which is a part of the Java heap that holds the VM's representation of the classfiles and other types in a java program. This is called "metadata" within hotspot. If there are a lot of classes loaded, the JVM can throw OutOfMemoryError for the permanent generation when there is plenty of Java heap space and native C heap space available. The customer would then need to restart the VM with a larger MaxPermSize parameter.
One of the solutions to this problem is to use native C memory for the VM's representation of the Java program. This is currently our chosen solution. The SymbolTable and associated symbols are one type in the JVM that needs to move into native memory, from permgen. The symbols are shared among class loaders so need to be reference counted so that when unreferenced, they are freed.
This work supports bugid 6964458
Posted Date : 2010-10-08 20:24:43.0
One of the solutions to this problem is to use native C memory for the VM's representation of the Java program. This is currently our chosen solution. The SymbolTable and associated symbols are one type in the JVM that needs to move into native memory, from permgen. The symbols are shared among class loaders so need to be reference counted so that when unreferenced, they are freed.
This work supports bugid 6964458
Posted Date : 2010-10-08 20:24:43.0
2010-11-05
Request for review (XL) 6990754: Use native memory and reference counting to implement SymbolTable
http://bugs.sun.com/view_bug.do?bug_id=7019689 << 关联bug
http://bugs.sun.com/view_bug.do?bug_id=7019165 << 关联bug
Bug ID: 7019165
Votes 0
Synopsis Incorrect symbols in pstack output after SymbolTable changes
Category hotspot:runtime_system
Reported Against
Release Fixed hs21(b05), 7(b135) (Bug ID:2208133)
State 11-Closed, Unverified, bug
Priority: 3-Medium
Related Bugs 6990754
Submit Date 11-FEB-2011
2011-01-27
HotSpot要干掉PermGen了…
OpenJDK 7/HotSpot revision 3582bf76420e (changeset 2059): 6990754: Use native memory and reference counting to implement SymbolTable
引用
6990754: Use native memory and reference counting to implement SymbolTable
Summary: move symbols from permgen into C heap and reference count them
Reviewed-by: never, acorn, jmasa, stefank
Summary: move symbols from permgen into C heap and reference count them
Reviewed-by: never, acorn, jmasa, stefank
第一个code push已经上OpenJDK 7了,
2011-02-10
JDK7 build 129
JDK7 build 129里的HotSpot 21已经开始移除PermGen,改为引用计数方式在native heap上管理SymbolTable
所以现在在HotSpot中的oop继承结构中,老的symbolOopDesc已经消失,取而代之的是新的Symbol类。
Jon Masamitsu在hotspot-dev邮件列表里提到JDK7发布前可能来不及完成将PermGen移除的工作
Bug ID 7017732: move static fields into Class to prepare for perm gen removal
引用
Currently static fields are stored in the instanceKlass but when those are moved into native memory we'd have to have a new card mark strategy for static fields. This could be something like setting a flag in the instanceKlass and then rescanning every klass during a GC which seems expensive or marking the card for the java.lang.Class then making sure to scan the instanceKlass when scanning the Class. If we move them into the Class then almost all the existing machinery works exactly as it always has. The only execution difference is which constant is materialized for the field access.
Posted Date : 2011-02-07 21:49:13.0
Posted Date : 2011-02-07 21:49:13.0
引用
http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c7f3d0b4570f
Posted Date : 2011-03-19 02:15:44.0
7017732: move static fields into Class to prepare for perm gen removal
Reviewed-by: kvn, coleenp, twisti, stefank
Currently static fields are stored in the instanceKlass but when those
are moved into native memory we'd have to have a new card mark
strategy for static fields. This could be something like setting a
flag in the instanceKlass and then rescanning every klass during a GC
which seems expensive or marking the card for the java.lang.Class then
making sure to scan the instanceKlass when scanning the Class. If we
move them into the Class then almost all the existing machinery works
exactly as it always has. The only execution difference is which
constant is materialized for the field access.
Most of the machinery for static fields is now over in
javaClasses.cpp. The bootstrap had to change slightly since we don't
have Class until we've loaded a few classes but it all fits into the
existing mirror creation logic. I also only create mirrors for real
Java classes whereas previously we also created them for internal
klasses we create.
The main implementation oddity is that java.lang.Class instances are
now variably sized. This required a small change in size_given_klass
and a new instanceMirrorKlass to handle visiting the oops in them.
Performance is unchanged. Tested with ctw, runthese, nsk jvmti tests
and jbb with the various collectors.
Posted Date : 2011-03-22 03:22:38.0
Posted Date : 2011-03-19 02:15:44.0
7017732: move static fields into Class to prepare for perm gen removal
Reviewed-by: kvn, coleenp, twisti, stefank
Currently static fields are stored in the instanceKlass but when those
are moved into native memory we'd have to have a new card mark
strategy for static fields. This could be something like setting a
flag in the instanceKlass and then rescanning every klass during a GC
which seems expensive or marking the card for the java.lang.Class then
making sure to scan the instanceKlass when scanning the Class. If we
move them into the Class then almost all the existing machinery works
exactly as it always has. The only execution difference is which
constant is materialized for the field access.
Most of the machinery for static fields is now over in
javaClasses.cpp. The bootstrap had to change slightly since we don't
have Class until we've loaded a few classes but it all fits into the
existing mirror creation logic. I also only create mirrors for real
Java classes whereas previously we also created them for internal
klasses we create.
The main implementation oddity is that java.lang.Class instances are
now variably sized. This required a small change in size_given_klass
and a new instanceMirrorKlass to handle visiting the oops in them.
Performance is unchanged. Tested with ctw, runthese, nsk jvmti tests
and jbb with the various collectors.
Posted Date : 2011-03-22 03:22:38.0
经过这个修改后,java.lang.Class就变成HotSpot VM里的一个特例了:虽然它是Java对象(而不是数组),但它的大小却是可变的(像数组而不像普通对象)。
关联的一个bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7030435
Some oop_oop_iterate_m() methods iterate outside of specified memory bounds
Bug ID 6962931: move interned strings out of the perm gen
引用
Interned strings are currently stored in the permanent generation. A new approach for managing meta-data is being designed and it requires interned strings to live elsewhere in the the heap (young gen and/or old gen).
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7032129
<< 关联bug
引用
The interned string changes allow interned strings to live in main heap instead of only perm so we can allocate significantly more interned strings before running out of heap.
The use of as_unicode_string in StringTable::verify creates a lot of native memory pressure during the verify since we allocate as much space here as there are char[]s interned. Maybe the code should just get a raw pointer to the char array or there should be a new routine that computes the hash directly from the array. A ResourceMark in the inner loop would work too.
Posted Date : 2011-03-29 17:09:03.0
http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/352622fd140a
Posted Date : 2011-04-01 00:29:39.0
7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests
Reviewed-by: kvn, kamg, jcoomes
StringTable::verify uses as_unicode_string to verify the hash code we
keep in the table but the only resource mark is outside the loop.
This means that verification makes a copy of the entire StringTable in
a resource area. Now that interned strings aren't in perm the
StringTable can become as large as the Java heap which means
verification can overflow the address space. The fix is to compute
the hash directly from the char[] instead of making a copy. I moved
the hash_string logic into java_lang_String and updated the users
appropriately. Tested with test case that allocates interned strings
until we run out of heap.
Posted Date : 2011-04-01 03:59:50.0
The use of as_unicode_string in StringTable::verify creates a lot of native memory pressure during the verify since we allocate as much space here as there are char[]s interned. Maybe the code should just get a raw pointer to the char array or there should be a new routine that computes the hash directly from the array. A ResourceMark in the inner loop would work too.
Posted Date : 2011-03-29 17:09:03.0
http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/352622fd140a
Posted Date : 2011-04-01 00:29:39.0
7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests
Reviewed-by: kvn, kamg, jcoomes
StringTable::verify uses as_unicode_string to verify the hash code we
keep in the table but the only resource mark is outside the loop.
This means that verification makes a copy of the entire StringTable in
a resource area. Now that interned strings aren't in perm the
StringTable can become as large as the Java heap which means
verification can overflow the address space. The fix is to compute
the hash directly from the char[] instead of making a copy. I moved
the hash_string logic into java_lang_String and updated the users
appropriately. Tested with test case that allocates interned strings
until we run out of heap.
Posted Date : 2011-04-01 03:59:50.0
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003421
8003421: NPG: Move oops out of InstanceKlass into mirror
引用
After permgen removal, the only oops that need to be walked in class metadata are in InstanceKlass besides mirrors are protection_domain, signers, init_lock. If these fields are moved to the mirror there is no increase in overall footprint. Also these fields can be card marked when modified because mirrors generally get promoted to tenured early, so that young collections don't need to look at these in our metadata (only mirrors).
This would be supportive of MVM because the mirror and these fields cannot be shared between classes so if the InstanceKlass is shared, these things are kept separately in an array indexed by task id. If these things were in the mirror, we'd only have to worry about the mirror in this array. The init_lock had to be virtualized in the MVM prototype. We had extra code that would lock the per-task information as an oop, so this would also be supportive of that.
In javaClasses.hpp there is a mechanism for injecting fields into our known Java objects, so I don't think this is difficult.
This would be supportive of MVM because the mirror and these fields cannot be shared between classes so if the InstanceKlass is shared, these things are kept separately in an array indexed by task id. If these things were in the mirror, we'd only have to worry about the mirror in this array. The init_lock had to be virtualized in the MVM prototype. We had extra code that would lock the per-task information as an oop, so this would also be supportive of that.
In javaClasses.hpp there is a mechanism for injecting fields into our known Java objects, so I don't think this is difficult.
=========================================================================
Java虚拟机规范第二版提到:3.5.4 Method Area
The Java Virtual Machine Specification, Second Edition 写道
3.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 a UNIX 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 (§3.9) used in class and instance initialization and interface type 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.
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 a UNIX 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 (§3.9) used in class and instance initialization and interface type 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.
The Java HotSpot Performance Engine Architecture
引用
Reflective Data are Represented as Objects
Classes, methods, and other internal reflective data are represented directly as objects on the heap (although those objects may not be directly accessible to Java technology-based programs). This not only simplifies the VM internal object model, but also allows classes to be collected by the same garbage collector used for other Java programming language objects.
Classes, methods, and other internal reflective data are represented directly as objects on the heap (although those objects may not be directly accessible to Java technology-based programs). This not only simplifies the VM internal object model, but also allows classes to be collected by the same garbage collector used for other Java programming language objects.
HotSpot Runtime Overview
引用
Class Metadata in HotSpot
Class loading creates either an instanceKlass or an arrayKlass in the GC permanent generation. The instanceKlass refers to a java mirror, which is the instance of java.lang.Class mirroring this class. The VM C++ access to the instanceKlass is via a klassOop.
Class loading creates either an instanceKlass or an arrayKlass in the GC permanent generation. The instanceKlass refers to a java mirror, which is the instance of java.lang.Class mirroring this class. The VM C++ access to the instanceKlass is via a klassOop.
Storage Management
引用
The Permanent Generation
In addition to the objects created by the Java application, there are objects created and used by the HotSpot virtual machine whose storage it is convenient to have allocated and recovered by the storage manager. To avoid confusing things, such objects are allocated in a separate generation, the so-called “permanent” generation. In fact, the objects in it are not “permanent”, but that's what it has been called historically. For example, information about loaded classes is stored in the permanent generation, and recovered when those classes are no longer reachable from the application.
In addition to the objects created by the Java application, there are objects created and used by the HotSpot virtual machine whose storage it is convenient to have allocated and recovered by the storage manager. To avoid confusing things, such objects are allocated in a separate generation, the so-called “permanent” generation. In fact, the objects in it are not “permanent”, but that's what it has been called historically. For example, information about loaded classes is stored in the permanent generation, and recovered when those classes are no longer reachable from the application.
Troubleshooting Guide for Java SE 6 with HotSpot VM
引用
2.7.4 Getting Information on the Permanent Generation
The permanent generation is the area of heap that holds all the reflective data of the virtual machine itself, such as class and method objects (also called “method area” in The Java Virtual Machine Specification). This area also holds internalized strings.
The permanent generation is the area of heap that holds all the reflective data of the virtual machine itself, such as class and method objects (also called “method area” in The Java Virtual Machine Specification). This area also holds internalized strings.
评论
2 楼
RednaxelaFX
2011-07-25
chenchao051 写道
文章太长了,没看完啊,看到这段,难道PermGen的移除就是为了更好的处理dynamic languages在JVM上的运行码? 还有啥原因吗?猜测也行啊,哈哈。 工作中,忙里偷闲啊。。。
我想说的在这个回帖里已经都说了:http://www.iteye.com/topic/1112592?page=2#2216243。没啥需要加的。
1 楼
chenchao051
2011-07-25
Allex Miller 写道
The permgen improvement is really needed to address a problem that has been getting worse with dynamic languages running on the JVM. Many of these languages like Groovy or JRuby dynamically generate large numbers of small classes at execution time to provide the dynamic behavior. These classes pollute the special "permgen" parts of Java memory and are difficult or impossible to reclaim, causing significant memory problems. The JSR 292 invokedynamic work is addressing some of this problem in another way by allowing dynamic languages to directly link call sites at runtime, avoiding the need to generate many of those internal classes at all.
文章太长了,没看完啊,看到这段,难道PermGen的移除就是为了更好的处理dynamic languages在JVM上的运行码? 还有啥原因吗?猜测也行啊,哈哈。 工作中,忙里偷闲啊。。。
The permgen improvement is really needed to address a problem that has been getting worse with dynamic languages running on the JVM. Many of these languages like Groovy or JRuby dynamically generate large numbers of small classes at execution time to provide the dynamic behavior. These classes pollute the special "permgen" parts of Java memory and are difficult or impossible to reclaim, causing significant memory problems. The JSR 292 invokedynamic work is addressing some of this problem in another way by allowing dynamic languages to directly link call sites at runtime, avoiding the need to generate many of those internal classes at all.
文章太长了,没看完啊,看到这段,难道PermGen的移除就是为了更好的处理dynamic languages在JVM上的运行码? 还有啥原因吗?猜测也行啊,哈哈。 工作中,忙里偷闲啊。。。
发表评论
-
The Prehistory of Java, HotSpot and Train
2014-06-02 08:18 0http://cs.gmu.edu/cne/itcore/vi ... -
MSJVM and Sun 1.0.x/1.1.x
2014-05-20 18:50 0当年的survey paper: http://www.sym ... -
Sun JDK1.4.2_28有TieredCompilation
2014-05-12 08:48 0原来以前Sun的JDK 1.4.2 update 28就已经有 ... -
IBM JVM notes (2014 ver)
2014-05-11 07:16 0Sovereign JIT http://publib.bou ... -
class data sharing by Apple
2014-03-28 05:17 0class data sharing is implement ... -
Java 8与静态工具类
2014-03-19 08:43 16266以前要在Java里实现所谓“静态工具类”(static uti ... -
Java 8的default method与method resolution
2014-03-19 02:23 10448先看看下面这个代码例子, interface IFoo { ... -
HotSpot Server VM与Server Class Machine
2014-02-18 13:21 0HotSpot VM历来有Client VM与Server V ... -
Java 8的lambda表达式在OpenJDK8中的实现
2014-02-04 12:08 0三月份JDK8就要发布首发了,现在JDK8 release c ... -
GC stack map与deopt stack map的异同
2014-01-08 09:56 0两者之间不并存在包含关系。它们有交集,但也各自有特别的地方。 ... -
HotSpot Server Compiler与data-flow analysis
2014-01-07 17:41 0http://en.wikipedia.org/wiki/Da ... -
基于LLVM实现VM的JIT的一些痛点
2014-01-07 17:25 0同事Philip Reames Sanjoy Das http ... -
tailcall notes
2013-12-27 07:42 0http://blogs.msdn.com/b/clrcode ... -
《自制编程语言》的一些笔记
2013-11-24 00:20 0http://kmaebashi.com/programmer ... -
字符串的一般封装方式的内存布局 (1): 元数据与字符串内容,整体还是分离?
2013-11-07 17:44 22385(Disclaimer:未经许可请 ... -
字符串的一般封装方式的内存布局 (0): 拿在手上的是什么
2013-11-04 18:22 21486(Disclaimer:未经许可请 ... -
字符串的一般封装方式的内存布局
2013-11-01 12:55 0(Disclaimer:未经许可请 ... -
关于string,内存布局,C++ std::string,CoW
2013-10-30 20:45 0(Disclaimer:未经许可请 ... -
对C语义的for循环的基本代码生成模式
2013-10-19 23:12 21866之前有同学在做龙书(第二版)题目,做到8.4的练习,跟我对答案 ... -
Java的instanceof是如何实现的
2013-09-22 16:57 0Java语言规范,Java SE 7版 http://docs ...
相关推荐
在Java 8之前,PermGen space 是HotSpot JVM的一部分,并且它的大小可以通过JVM参数进行调整。 当PermGen space的可用空间被耗尽时,Java应用程序将抛出`java.lang.OutOfMemoryError: PermGen space`异常。这种错误...
在Java 8中,Oracle决定移除PermGen,并引入元空间作为替代。元空间使用本地内存,而不是像PermGen那样在Java堆内存中分配。这意味着元空间的大小不再受到Java堆大小的限制,而是依赖于操作系统的可用虚拟内存。这...
对于正在使用Java SE 6和HotSpot VM的开发者来说,这份文档是不可或缺的参考资料之一。通过对文档内容的理解和实践应用,可以帮助他们更加高效地解决实际工作中的问题,提高软件系统的稳定性和可靠性。
HotSpot VM是Oracle JDK中默认的JVM实现,它提供了一种称为HSDB(HotSpot Debugger Bridge)的工具,用于在运行时查看和分析JVM内部的数据。本篇将通过HSDB的使用案例来探讨HotSpot VM的运行时数据。 首先,我们...
Compilation in the HotSpot VM 是一篇关于 Java 虚拟机(Java Virtual Machine,JVM)的技术文档, 由 Oracle 公司的 HotSpot 编译器团队的 Zoltán Majó 撰写。该文档详细介绍了 HotSpot JVM 中的编译过程,包括...
【Java HotSpot VM Serial GC详解】 HotSpot VM的Serial GC是一种单线程的垃圾收集器,主要用于新生代的垃圾回收,特别适用于轻量级和低内存的环境。在这个话题中,我们将深入探讨Serial GC在新生代(Young ...
Hotspot VM的名字来源于其核心理念——热点代码检测,即自动识别并优化执行频繁的代码段,从而提高整体程序的运行效率。本文将围绕Hotspot VM的源码进行深入探讨,揭示其内部工作机制。 一、Hotspot VM的架构 ...
本篇文章将深入探讨HotSpot VM的运行时数据结构,以理解标题中提到的`t1`、`t2`和`t3`变量在内存中的存储位置。 首先,我们来看一下给出的Java代码片段: ```java public class Test { static Test2 t1 = new ...
1. **Java HotSpot虚拟机的JIT编译**:HotSpot是Java虚拟机的一个实现版本,由Oracle公司开发。它对运行在Java平台上的应用程序执行高效的JIT编译,将Java字节码转换成本地机器码以提高性能。JIT编译能够在程序运行...
【描述】:本篇文章旨在探讨Java内存模型中不同类型的变量——包括静态变量t1、实例变量t2和局部变量t3——在HotSpot VM中的存储位置。我们将借助HSDB(HotSpot Serviceability Agent的调试器)来探索实际运行时的...
Oracle HotSpot Virtual Machine 垃圾回收机制详解 Oracle HotSpot Virtual Machine 是 Java 平台标准版中的垃圾回收机制,负责管理 Java 应用程序中的内存资源。本文档将对 Oracle HotSpot Virtual Machine 垃圾...
HotSpot正是目前世界上java虚拟机的最好的实现。 HotSpot的基础代码是许多人辛勤劳动的结晶,这个过程迄今已持续了超过10年的时间(当然时间长并不意味着一定好,一半一半吧)。所以到现在为止,他的体积是很大的。...
HotSpot虚拟机是Oracle JDK中的关键部分,它是Java程序运行的引擎。HotSpot包括一个即时编译器(JIT),它能够在运行时将频繁执行的字节码转化为机器码,从而提升程序的运行速度。JDK 1.8的HotSpot可能包含了优化的...
学习JDK 源码必备,提起HotSpot VM,相信所有Java程序员都知道,它是Sun JDK和OpenJDK中所带的虚拟机,也是目前使用范围最广的Java虚拟机。 但不一定所有人都知道的是,这个目前看起来“血统纯正”的虚拟机在最初...
The authors, who are all leading Java performance and Java HotSpot VM experts, help you improve performance by using modern software engineering practices, avoiding common mistakes, and applying tips ...
Oracle公司计划在未来版本的JDK中整合这两种虚拟机的优势特性,例如使用JRockit的垃圾回收机制和Mission Control服务,同时保留HotSpot的JIT编译器和混合运行时系统。 #### 二、Java内存结构 Java内存模型主要包括...
这次收购加强了Oracle在企业级Java应用程序市场的地位,使得Oracle可以整合JRockit的优秀特性与自身HotSpot JVM,最终在后续版本中推出了Oracle JVM,即现在的Oracle Java SE。 **Jrockit-j2sdk1.4.2_05-win-ia32....
- **PermGen**(永久代):特定于Sun HotSpot VM的一种内存区域,用于存储类元数据等信息。需要注意的是,在Java 7及以后版本中,永久代已经被Metaspace取代。 - **Native Heap (C-Heap)**:所有JVM厂商都会使用的一...