借助HotSpot SA来一窥PermGen上的对象

最新推荐文章于 2020-11-17 15:23:19 发布
最新推荐文章于 2020-11-17 15:23:19 发布
阅读量1.3k 收藏 4
点赞数 1
分类专栏： J2EE 文章标签： 借助HotSpot SA来一窥PermG
（Disclaimer：如果需要转载请先与我联系； 
作者：RednaxelaFX -> rednaxelafx.iteye.com） 

接着 前天的与 昨天的帖，今天也来介绍一个 HotSpot的 Serviceability Agent（以下简称SA）的玩法例子。 

昨天用SA把x86机器码反汇编到汇编代码，或许对多数Java程序员来说并不怎么有趣。那么今天就来点更接近Java，但又经常被误解的话题——HotSpot的GC堆的permanent generation。 

要用SA里最底层的API来连接上一个Java进程并不困难，不过SA还提供了更方便的封装：只要继承 sun.jvm.hotspot.tools.Tool 并实现一个  run() 方法，在该方法内使用SA的API访问JVM即可。 

（或者更简单的：可以直接起CLHSDB，attach上之后运行下面这句就好 
Java代码   收藏代码
  1. jseval "sa.objHeap.iteratePerm(new sapkg.oops.HeapPrinter(java.lang.System.out))"  

做的事情跟本文后面的例子一样用iteratePerm()，而下面这句 
Java代码   收藏代码
  1. jseval "io = java.io; sa.objHeap.iteratePerm(new sapkg.oops.HeapPrinter(new io.PrintStream(new io.FileOutputStream('perm.log'))))"  

直接把PermGen内容输出到文件里去 
） 

这次我们就把一个跑在HotSpot上的Java进程的perm gen里所有对象的信息打到标准输出流上看看吧。 
测试环境是32位Linux，x86，Sun JDK 6 update 2 
（手边可用的JDK版本很多，随便拿了一个来用，呵呵 >_<） 

代码如下： 
Java代码   收藏代码
  1. import sun.jvm.hotspot.gc_implementation.parallelScavenge.PSPermGen;  
  2. import sun.jvm.hotspot.gc_implementation.parallelScavenge.ParallelScavengeHeap;  
  3. import sun.jvm.hotspot.gc_implementation.shared.MutableSpace;  
  4. import sun.jvm.hotspot.gc_interface.CollectedHeap;  
  5. import sun.jvm.hotspot.memory.Universe;  
  6. import sun.jvm.hotspot.oops.HeapPrinter;  
  7. import sun.jvm.hotspot.oops.HeapVisitor;  
  8. import sun.jvm.hotspot.oops.ObjectHeap;  
  9. import sun.jvm.hotspot.runtime.VM;  
  10. import sun.jvm.hotspot.tools.Tool;  
  11.   
  12. /** 
  13.  * @author sajia 
  14.  *  
  15.  */  
  16. public class TestPrintPSPermGen extends Tool {  
  17.     public static void main(String[] args) {  
  18.         TestPrintPSPermGen test = new TestPrintPSPermGen();  
  19.         test.start(args);  
  20.         test.stop();  
  21.     }  
  22.   
  23.     @Override  
  24.     public void run() {  
  25.         VM vm = VM.getVM();  
  26.         Universe universe = vm.getUniverse();  
  27.         CollectedHeap heap = universe.heap();  
  28.         puts("GC heap name: " + heap.kind());  
  29.         if (heap instanceof ParallelScavengeHeap) {  
  30.             ParallelScavengeHeap psHeap = (ParallelScavengeHeap) heap;  
  31.             PSPermGen perm = psHeap.permGen();  
  32.             MutableSpace permObjSpace = perm.objectSpace();  
  33.             puts("Perm gen: [" + permObjSpace.bottom() + ", " + permObjSpace.end() + ")");  
  34.             long permSize = 0;  
  35.             for (VM.Flag f : VM.getVM().getCommandLineFlags()) {  
  36.                 if ("PermSize".equals(f.getName())) {  
  37.                     permSize = Long.parseLong(f.getValue());  
  38.                     break;  
  39.                 }  
  40.             }  
  41.             puts("PermSize: " + permSize);  
  42.         }  
  43.         puts();  
  44.           
  45.         ObjectHeap objHeap = vm.getObjectHeap();  
  46.         HeapVisitor heapVisitor = new HeapPrinter(System.out);  
  47.         objHeap.iteratePerm(heapVisitor);  
  48.     }  
  49.       
  50.     private static void puts() {  
  51.         System.out.println();  
  52.     }  
  53.       
  54.     private static void puts(String s) {  
  55.         System.out.println(s);  
  56.     }  
  57. }  


很简单，假定目标Java进程用的是Parallel Scavenge（PS）算法的GC堆，输出GC堆的名字，当前perm gen的起始和结束地址，VM参数中设置的PermSize（perm gen的初始大小）；然后是perm gen中所有对象的信息，包括对象摘要、地址、每个成员域的名字、偏移量和值等。 
对HotSpot的VM参数不熟悉的同学可以留意一下几个参数在HotSpot源码中的定义： 
C++代码   收藏代码
  1. product(ccstrlist, OnOutOfMemoryError, "",  
  2.     "Run user-defined commands on first java.lang.OutOfMemoryError")  
  3. product(bool, UseParallelGC, false, "Use the Parallel Scavenge garbage collector")  
  4. product_pd(uintx, PermSize, "Initial size of permanent generation (in bytes)")  
  5. product_pd(uintx, MaxPermSize, "Maximum size of permanent generation (in bytes)")  


要让SA连接到一个正在运行的Java进程最重要是提供进程ID。获取pid的方法有很多，今天演示的是利用OnOutOfMemoryError参数指定让HotSpot在遇到内存不足而抛出OutOfMemoryError时执行一段用户指定的命令；在这个命令中可以使用%p占位符表示pid，HotSpot在执行命令时会把真实pid填充进去。 

然后来造一个引发OOM的导火索： 
Java代码   收藏代码
  1. public class Foo {  
  2.     public static void main(String[] args) {  
  3.         Long[] array = new Long[256*1024*1024];  
  4.     }  
  5. }  

对32位HotSpot来说，main()方法里的new Long[256*1024*1024]会试图创建一个大于1GB的数组对象，那么只要把-Xmx参数设到1GB或更小便足以引发OOM了。 
如何知道这个数组对象会占用超过1GB的呢？Long[]是一个引用类型的数组，只要知道32位HotSpot中采用的对象布局：  
            -----------------------
（+0）      |        _mark         |
            -----------------------
（+4）      |      _metadata       |
            -----------------------
（+8）      |    数组长度 length    |
            -----------------------
（+12+4*0） |     下标为0的元素      |
            -----------------------
（+12+4*1） |     下标为1的元素      |
            -----------------------
            |         ...          |
            -----------------------
（+12+4*n） |     下标为n的元素      |
            -----------------------
           |         ...          |
            -----------------------

就知道一大半了～ 


跑一下Foo程序。留意到依赖SA的代码要编译的话需要$JAVA_HOME/lib/sa-jdi.jar在classpath上，执行时同理。指定GC算法为Parallel Scavenge，并指定Java堆（不包括perm gen）的初始和最大值都为1GB： 
Command prompt代码 
  1. [sajia@sajia ~]$ java -server -version  
  2. java version "1.6.0_02"  
  3. Java(TM) SE Runtime Environment (build 1.6.0_02-b05)  
  4. Java HotSpot(TM) Server VM (build 1.6.0_02-b05, mixed mode)  
  5. [sajia@sajia ~]$ javac Foo.java  
  6. [sajia@sajia ~]$ javac -classpath ".:$JAVA_HOME/lib/sa-jdi.jar" TestPrintPSPermGen.java  
  7. [sajia@sajia ~]$ java -server -XX:+UseParallelGC -XX:OnOutOfMemoryError='java -cp $JAVA_HOME/lib/sa-jdi.jar:. TestPrintPSPermGen %p > foo.txt' -Xms1g -Xmx1g Foo  
  8. #  
  9. # java.lang.OutOfMemoryError: Java heap space  
  10. # -XX:OnOutOfMemoryError="java -cp $JAVA_HOME/lib/sa-jdi.jar:. TestPrintPSPermGen %p > foo.txt"  
  11. #   Executing /bin/sh -c "java -cp $JAVA_HOME/lib/sa-jdi.jar:. TestPrintPSPermGen 23373 > foo.txt"...  
  12. Attaching to process ID 23373, please wait...  
  13. Debugger attached successfully.  
  14. Server compiler detected.  
  15. JVM version is 1.6.0_02-b05  
  16. Exception in thread "main" java.lang.OutOfMemoryError: Java heap space  
  17.         at Foo.main(Foo.java:5)  
  18. [sajia@sajia ~]$   


得到的foo.txt就是要演示的输出结果。把它压缩了放在附件里，有兴趣但懒得自己实验的同学也可以观摩一下～ 

在foo.txt的开头可以看到： 
Log代码 
  1. GC heap name: ParallelScavengeHeap  
  2. Perm gen: [0x70e60000, 0x71e60000)  
  3. PermSize: 16777216  

这里显示了GC堆确实是Parallel Scavenge的，其中perm gen当前的起始地址为0x70e60000，结束地址为0x71e60000，中间连续的虚拟内存空间都分配给perm gen使用。简单计算一下可知perm gen大小为16MB，与下面打出的PermSize参数的值完全吻合。 

通过阅读该日志文件，可以得知HotSpot在perm gen里存放的对象主要有： 
- Klass系对象 
- java.lang.Class对象 
- 字符串常量 
- 符号（Symbol/symbolOop）常量 
- 常量池对象 
- 方法对象 
等等，以及它们所直接依赖的一些对象。具体这些都是什么留待以后有空再写。 


接下来挑几个例子来简单讲解一下如何阅读这个日志文件里的对象描述。 

首先看一个String对象。先看看JDK里java.lang.String对象的声明是什么样的： 
Java代码 
  1. package java.lang;  
  2.   
  3. // imports ...  
  4.   
  5. public final class String  
  6.     implements java.io.Serializable, Comparable<String>, CharSequence  
  7. {  
  8.     /** The value is used for character storage. */  
  9.     private final char value[];  
  10.       
  11.     /** The offset is the first index of the storage that is used. */  
  12.     private final int offset;  
  13.       
  14.     /** The count is the number of characters in the String. */  
  15.     private final int count;  
  16.       
  17.     /** Cache the hash code for the string */  
  18.     private int hash; // Default to 0  
  19.       
  20.     /** use serialVersionUID from JDK 1.0.2 for interoperability */  
  21.     private static final long serialVersionUID = -6849794470754667710L;  
  22.       
  23.     private static final ObjectStreamField[] serialPersistentFields =  
  24.         new ObjectStreamField[0];  
  25.       
  26.     public static final Comparator<String> CASE_INSENSITIVE_ORDER  
  27.                                          = new CaseInsensitiveComparator();  
  28.     private static class CaseInsensitiveComparator  
  29.                          implements Comparator<String>, java.io.Serializable {  
  30.         // ...  
  31.     }  
  32. }  

留意到String对象有4个成员域，分别是： 
名字类型引用类型还是值类型
valuechar[]引用类型
offsetint值类型
countint值类型
hashint值类型

String类自身有三个静态变量，分别是： 
名字类型引用类型还是值类型备注
serialVersionUIDlong值类型常量
serialPersistentFieldsjava.io.ObjectStreamField[]引用类型只读变量
CASE_INSENSITIVE_ORDERjava.lang.String.CaseInsensitiveComparator引用类型只读变量

回到我们的foo.txt日志文件来看一个String的对象实例： 
Log代码 
  1. "main" @ 0x7100b140 (object size = 24)  
  2.  - _mark:    {0} :1  
  3.  - _klass:   {4} :InstanceKlass for java/lang/String @ 0x70e6c6a0  
  4.  - value:    {8} :[C @ 0x7100b158  
  5.  - offset:   {12} :0  
  6.  - count:    {16} :4  
  7.  - hash:     {20} :0  

这是在HotSpot的字符串池里的一个字符串常量对象，"main"。 
日志中的“"main"”是对象的摘要，String对象有特别处理显示为它的内容，其它多数类型的对象都是显示类型名之类的。 
在@符号之后的就是对象的起始地址，十六进制表示。 
紧接着后面是对象占用GC堆的大小。很明显这个String对象自身占用了24字节。这里强调是“占用”的大小是因为对象除了存储必要的数据需要空间外，为了满足数据对齐的要求可能会有一部分空间作为填充数据而空占着。 

String在内存中的布局是：  
       -----------------------
（+0） |        _mark        |
       -----------------------
（+4） |      _metadata      |
       -----------------------
（+8） |        value        |
       -----------------------
（+12）|        offset       |
       -----------------------
（+16）|        count        |
       -----------------------
（+20）|        hash         |
       -----------------------

32位HotSpot上要求64位/8字节对齐，String占用的24字节正好全部都是有效数据，不需要填充空数据。 

上面的String实例在内存中的实际数据如下： 
偏移量（字节）数值（二进制表示）数值（十六进制表示）宽度（位/字节）
  +0000000000000000000000000000000010000000132位/4字节
  +40111000011100110110001101010000070e6c6a032位/4字节
  +8011100010000000010110001010110007100b15832位/4字节
+12000000000000000000000000000000000000000032位/4字节
+16000000000000000000000000000001000000000432位/4字节
+20000000000000000000000000000000000000000032位/4字节


OK，那我们来每个成员域都过一遍，看看有何玄机。 

第一个是_mark。在HotSpot的C++代码里它的类型是markOop，在SA里以sun.jvm.hotspot.oops.Mark来表现。 
它属于对象头（object header）的一部分，是个多用途标记，可用于记录GC的标记（mark）状态、锁状态、偏向锁（bias-locking）状态、身份哈希值（identity hash）缓存等等。它的可能组合包括： 
比特域（名字或常量值:位数）标识（tag） 状态
身份哈希值:25, 年龄:4, 0:101 未锁
锁记录地址:3000 被轻量级锁住
monitor对象地址:3010 被重量级锁住
转向地址:3011 被GC标记
线程ID:23, 纪元:2, 年龄:4, 1:101 被偏向锁住/可被偏向锁

例子中的"main"字符串的_mark值为1，也就是说它： 
- 没有被锁住； 
- 现在未被GC标记； 
- 年龄为0（尚未经历过GC）； 
- 身份哈希值尚未被计算。 

HotSpot的GC堆中许多创建没多久的对象的_mark值都会是1，属于正常现象。 


接下来看SA输出的日志中写为_klass而在我的图示上写为_metadata的这个域。 
在HotSpot的C++代码里，oopDesc是所有放在GC堆上的对象的顶层类，它的成员就构成了对象头。HotSpot在C++代码中用instanceOopDesc类来表示Java对象，而该类继承oopDesc，所以HotSpot中的Java对象也自然拥有oopDesc所声明的头部。 
hotspot/src/share/vm/oops/oop.hpp： 
C++代码 
  1. class oopDesc {  
  2.  private:  
  3.   volatile markOop  _mark;  
  4.   union _metadata {  
  5.     wideKlassOop    _klass;  
  6.     narrowOop       _compressed_klass;  
  7.   } _metadata;  
  8. };  

_metadata与前面提过的_mark一同构成了对象头。 
_metadata是个union，为了能兼容32位、64位与开了压缩指针（CompressedOops）等几种情况。无论是这个union中的_klass还是_compressed_klass域，它们都是用于指向一个描述该对象的klass对象的指针。SA的API屏蔽了普通指针与压缩指针之间的差异，所以就直接把_metadata._klass称为了_klass。 

对象头的格式是固定的，而对象自身内容的布局则由HotSpot根据一定规则来决定。Java类在被HotSpot加载时，其对象实例的布局与类自身的布局都会被计算出来。这个计算规则有机会以后再详细写。 

现在来看看"main"这个String对象实例自身的域都是些什么。 
value：指向真正保存字符串内容的对象的引用。留意Java里String并不把真正的字符内容直接存在自己里面，而是引用一个char[]对象来承载真正的存储。 
从Java一侧看value域的类型是char[]，而从HotSpot的C++代码来看它就是个普通的指针而已。它当前值是0x7100b158，指向一个char[]对象的起始位置。 
offset：字符串的内容从value指向的char[]中的第几个字符开始算（0-based）。int型，32位带符号整数，这从Java和C++来看都差不多。当前值为0。 
count：该字符串的长度，或者说包含的UTF-16字符的个数。类型同上。当前值为4，说明该字符串有4个UTF-16字符。 
hash：缓存该String对象的哈希值的成员域。类型同上。当前值为0，说明该实例的String.hashCode()方法尚未被调用过，因而尚未缓存住该字符串的哈希值。 

String对象的成员域都走过一遍了，来看看value所指向的对象状况。 
Log代码 
  1. [C @ 0x7100b158 (object size = 24)  
  2.  - _mark:    {0} :1  
  3.  - _klass:   {4} :TypeArrayKlass for [C @ 0x70e60440  
  4.  - _length:  {8} :4  
  5.  - 0:    {12} :m  
  6.  - 1:    {14} :a  
  7.  - 2:    {16} :i  
  8.  - 3:    {18} :n  

这就是"main"字符串的value所引用的char[]的日志。 
[C 是char[]在JVM中的内部名称。 
在@符号之后的0x7100b158是该对象的起始地址。 
该对象占用GC堆的大小是24字节。留意了哦。 

看看它的成员域。 

_mark与_klass构成的对象头就不重复介绍了。可以留意的是元素类型为原始类型（boolean、char、short、int、long、float、double）的数组在HotSpot的C++代码里是用typeArrayOopDesc来表示的；这里的char[]也不例外。描述typeArrayOopDesc的klass对象是typeArrayKlass类型的，所以可以看到日志里_klass的值写着TypeArrayKlass for [C。 

接下来是_length域。HotSpot中，数组对象比普通对象的头要多一个域，正是这个描述数组元素个数的_length。Java语言中数组的.length属性、JVM字节码中的arraylength要取的也正是这个值。 
日志中的这个数组对象有4个字符，所以_length值为4。 

再后面就是数组的内容了。于是该char[]在内存中的布局是：  
        -----------------------
（+0）  |        _mark         |
        -----------------------
（+4）  |      _metadata       |
        -----------------------
（+8）  |    数组长度 length    |
        -----------------------
（+12） |  char[0] | char[1]   |
        -----------------------
（+16） |  char[2] | char[3]   |
        -----------------------
（+20） |         填充0         |
        -----------------------

Java的char是UTF-16字符，宽度是16位/2字节；4个字符需要8字节，加上对象头的4*3=12字节，总共需要20字节。但该char[]却占用了GC堆上的24字节，正是因为前面提到的数据对齐要求——HotSpot要求GC堆上的对象是8字节对齐的，20向上找最近的8的倍数就是24了。用于对齐的这部分会被填充为0。 


"main"对象的value指向的char[]也介绍过了，回过头来看看它的_metadata._klass所指向的klass对象又是什么状况。 

从HotSpot的角度来看，klass就是用于描述GC堆上的对象的对象；如果一个对象的大小、域的个数与类型等信息不固定的话，它就需要特定的klass对象来描述。 
instanceOopDesc用于表示Java对象，instanceKlass用于描述它，但自身却又有些不固定的信息需要被描述，因而又有instanceKlassKlass；如此下去会没完没了，所以有个klassKlass作为这个描述链上的终结符。 
klass的关系图： 

（图片来源） 

回到foo.txt日志文件上来，找到"main"对象的_klass域所引用的instanceKlass对象： 
Log代码 
  1. InstanceKlass for java/lang/String @ 0x70e6c6a0 (object size = 384)  
  2.  - _mark:    {0} :1  
  3.  - _klass:   {4} :InstanceKlassKlass @ 0x70e60168  
  4.  - _java_mirror:     {60} :Oop for java/lang/Class @ 0x70e77760  
  5.  - _super:   {64} :InstanceKlass for java/lang/Object @ 0x70e65af8  
  6.  - _size_helper:     {12} :6  
  7.  - _name:    {68} :#java/lang/String @ 0x70e613e8  
  8.  - _access_flags:    {84} :134217777  
  9.  - _subklass:    {72} :null  
  10.  - _next_sibling:    {76} :InstanceKlass for java/lang/CharSequence @ 0x70e680e8  
  11.  - _alloc_count:     {88} :0  
  12.  - _array_klasses:   {112} :ObjArrayKlass for InstanceKlass for java/lang/String @ 0x70ef6298  
  13.  - _methods:     {116} :ObjArray @ 0x70e682a0  
  14.  - _method_ordering:     {120} :[I @ 0x70e61330  
  15.  - _local_interfaces:    {124} :ObjArray @ 0x70e67998  
  16.  - _transitive_interfaces:   {128} :ObjArray @ 0x70e67998  
  17.  - _nof_implementors:    {268} :0  
  18.  - _implementors[0]:     {164} :null  
  19.  - _implementors[0]:     {168} :null  
  20.  - _fields:  {132} :[S @ 0x70e68230  
  21.  - _constants:   {136} :ConstantPool for java/lang/String @ 0x70e65c38  
  22.  - _class_loader:    {140} :null  
  23.  - _protection_domain:   {144} :null  
  24.  - _signers:     {148} :null  
  25.  - _source_file_name:    {152} :#String.java @ 0x70e67980  
  26.  - _inner_classes:   {160} :[S @ 0x70e6c820  
  27.  - _nonstatic_field_size:    {196} :4  
  28.  - _static_field_size:   {200} :4  
  29.  - _static_oop_field_size:   {204} :2  
  30.  - _nonstatic_oop_map_size:  {208} :1  
  31.  - _is_marked_dependent:     {212} :0  
  32.  - _init_state:  {220} :5  
  33.  - _vtable_len:  {228} :5  
  34.  - _itable_len:  {232} :9  
  35.  - serialVersionUID:     {368} :-6849794470754667710  
  36.  - serialPersistentFields:   {360} :ObjArray @ 0x74e882c8  
  37.  - CASE_INSENSITIVE_ORDER:   {364} :Oop for java/lang/String$CaseInsensitiveComparator @ 0x74e882c0  

还记得上文提到过的String类的3个静态变量么？有没有觉得有什么眼熟的地方？ 
没错，在HotSpot中，Java类的静态变量就是作为该类对应的instanceKlass的实例变量出现的。上面的日志里最后三行描述了String的静态变量所在。 
这是件非常自然的事：类用于描述对象，类自身也是对象，有用于描述自身的类；某个类的所谓“静态变量”就是该类对象的实例变量。很多对象系统都是这么设计的。HotSpot的这套oop体系（指“普通对象指针”，不是指“面向对象编程”）继承自 Strongtalk，实际上反而比暴露给Java的对象模型显得更加面向对象一些。 

HotSpot并不把instanceKlass暴露给Java，而会另外创建对应的java.lang.Class对象，并将后者称为前者的“Java镜像”，两者之间互相持有引用。日志中的_java_mirror便是该instanceKlass对Class对象的引用。 
镜像机制被认为是良好的面向对象的反射与元编程设计的重要机制。Gilad Bracha与David Ungar还专门写了篇论文来阐述此观点，参考 Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Languages。 

顺带把"main"对象的_klass链上余下的两个对象的日志也贴出来： 
Log代码 
  1. InstanceKlassKlass @ 0x70e60168 (object size = 120)  
  2.  - _mark:    {0} :1  
  3.  - _klass:   {4} :KlassKlass @ 0x70e60000  
  4.  - _java_mirror:     {60} :Oop for java/lang/Class @ 0x70e76f20  
  5.  - _super:   {64} :null  
  6.  - _size_helper:     {12} :0  
  7.  - _name:    {68} :null  
  8.  - _access_flags:    {84} :0  
  9.  - _subklass:    {72} :null  
  10.  - _next_sibling:    {76} :null  
  11.  - _alloc_count:     {88} :0  

所有instanceKlass对象都是被这个instanceKlassKlass对象所描述的。 

Log代码 
  1. KlassKlass @ 0x70e60000 (object size = 120)  
  2.  - _mark:    {0} :1  
  3.  - _klass:   {4} :KlassKlass @ 0x70e60000  
  4.  - _java_mirror:     {60} :Oop for java/lang/Class @ 0x70e76e00  
  5.  - _super:   {64} :null  
  6.  - _size_helper:     {12} :0  
  7.  - _name:    {68} :null  
  8.  - _access_flags:    {84} :0  
  9.  - _subklass:    {72} :null  
  10.  - _next_sibling:    {76} :null  
  11.  - _alloc_count:     {88} :0  

而所有*KlassKlass对象都是被这个klassKlass对象所描述的。 

klass对象的更详细的介绍也留待以后再写吧～至少得找时间写写instanceKlass与vtable、itable的故事。 

嘛，今天的废话到此结束 ^_^ 
希望这帖能解答先前 关于java里面的全局变量的内存分配一帖中的疑问。也希望大家能多多支持 高级语言虚拟机圈子，有什么HLL VM相关的话题想讨论的欢迎来转转～
  • foo.zip (1.7 MB)
  • 描述: 文中例子的输出
  • 下载次数: 145
分享到：   
 |  借助HotSpot SA来反汇编
评论
19 楼  jjzhk 2014-12-15  
jjzhk 写道
HotSpot并不把instanceKlass暴露给Java，而会另外创建对应的java.lang.Class对象，并将后者称为前者的“Java镜像”，两者之间互相持有引用。

这句中的java.lang.Class对象是否应该是java.lang.String对象？
谢谢R大神。


我理解错了。。。呵呵。
18 楼  jjzhk 2014-12-15  
HotSpot并不把instanceKlass暴露给Java，而会另外创建对应的java.lang.Class对象，并将后者称为前者的“Java镜像”，两者之间互相持有引用。

这句中的java.lang.Class对象是否应该是java.lang.String对象？
谢谢R大神。
17 楼  lucky_huhu 2014-01-21  
期待R大“找时间写写instanceKlass与vtable、itable的故事”
16 楼  zuoyefeng1 2012-09-14  
话说要再看一遍编译原理的兄弟，这篇文章里说的与编译原理有毛关系，看来是没有学过编译原理的，或者是编译原理课逃课，连编译原理课本目录都没看过的。
15 楼  kingkan 2011-12-20  
呵呵，撒迦的这篇文章，对我帮助很大，解开了我的一些疑虑哈，藏了。--虚空
14 楼  coffeesweet 2010-08-09  
我要是有时间天天研究这些东西肯定也挺爽，羡慕楼主......
13 楼  sulifeng 2010-08-09  
牛人啊大神啊..................
12 楼  lianj_lee 2010-08-06  
确实有点入魔了. 


说实话, 很多东西都到了底层!
11 楼  gstarwd 2010-08-06  
哇 大爱~~
10 楼  divenLai 2010-08-06  
很好，很强大
9 楼  AlwenS 2010-08-06  
看完鸟,楼主的动手能力真强。  

我也喜欢探究这些东西，只是功力还不如楼主深。 

其实这东东和编译原理倒没多大关系了，主要看的是具体OO语言的Runtime Env模型。 
比如c++就是没有penmgen的，所以他的动态能力和RTTI都非常弱。
8 楼  seraphim871211 2010-08-06  
“大叔”，你最近的帖子都看不下去了。。。
7 楼  hymanyung 2010-08-06  
看得頭暈了.
6 楼  liujun999999 2010-08-06  
晕，说实话，我没有看懂，看出差距来了，唉
5 楼  kaka2008 2010-08-06  
fx同学出手即精华
而且帖子太深奥。。。
4 楼  reilost 2010-08-06  
-。-fx同学威武。。每次看你的帖子都想回去再看一遍编译原理
3 楼  youjianbo_han_87 2010-08-06  
确实不错，基础基础。
2 楼  kimmking 2010-08-06  
RednaxelaFX 的帖子，太深奥了。 
我找本编译原理补补先。
1 楼  melin 2010-08-06  
兄弟有点入魔了。。。
onyas
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
HotSpot虚拟机对象探秘-xmind脑图pdf
03-11
资源描述： 1.HotSpot虚拟机对象探秘-xmind脑图pdf 2.资源内容:HotSpot虚拟机对象探秘 3.学习目标:了解jvm底层原理 4.特点：简单易懂，容易上手 5.使用说明：需要使用pdf打开
解决import sun包时error
iteye_19934的博客
04-16 471
解决import sun包时error   错误情景： import sun.net.dns.ResolverConfiguration; import sun.net.util.IPAddressUtil; 编译器提示Error 解决方案： 如果你用的是Eclipse    在preference-&gt;java-&gt;complier-&gt;erro...
jvm常用工具
sun123game的博客
08-08 3469
1. jps     用来查看JVM信息，所有具有访问权限的java进程的具体状态。包括PID， 进程启动路径以及启动参数等。 可以理解为linux上的PS 子集。  命令格式: jps [-q] [-mlvV] []   -q  只输出pid   -m 输出传递给main方法的参数   -l    输出应用程序住类的完整包名，或者是应用程序jar文件的完
关于Sun HotSpot JVM的相关要点
qian0021514578
04-08 104
1、JVM的模式：(1).-server==&gt;优化模式，启动时慢，但运行时快，比client性能高，一般的web应用都建议JVM用此模式。(2).-client ==&gt;GUI时用此模式好，启动应用时比-server模式快。(3).-Xint ==&gt;解释器模式JVM默认的模式，可以通过java -version查看。2、JVM Memory Structure:(1).Metho...
JDK7底层C++源码及hotspot虚拟机源码
12-14
JDK7底层C++源码及hotspot虚拟机源码
dai147444612#JVM#HotSpot虚拟机对象探秘1
07-25
对象的创建加载：先去检测new指令能否再常量池中定位到一个类的符号引用，如果未被加载、解析、初始化过 执行相应的类加载过程分配内存: 为对象分配空间时采用指针碰
Antamedia-HotSpot.rar_Hotspot
09-19
Sample licensing code file for Antamedia HotSpot
hotspot 源码（JDK8）
11-10
jdk8u-hotspot
HotSpot实战
05-09
《HotSpot实战》深入浅出地讲解了HotSpot虚拟机的工作原理，将隐藏在它内部的本质内容逐一呈现在读者面前，包括OpenJDK与HotSpot项目、编译和调试HotSpot的方法、HotSpot内核结构、Launcher、OOP-Klass对象表示系统...
hllvm.HotSpot VM Serial GC的一个问题1
08-04
実装​》第4章4.4小节​. 每个版本的算法描述都稍微不同,我的伪代码也跟这两本书写的方式稍微不同,但背后要表达的核心思想是一样的就OK了.Tracing GC
hotspot.tar.gz
12-07
官方完整版JVM源码Hotspot VM，文件名hotspot.tar.gz。官方完整版JVM源码Hotspot VM，文件名hotspot.tar.gz。
java-jdk-hotspot源码
08-07
它来源于Strongtalk VM， 而这款虚拟机中相当多的技术又是来源于一款支持Self语言实现“达到C语言50%以上的执行效率”的目标而设计的虚拟机， Sun公司注意到了这款虚拟机在JIT编译上有许多优秀的理念和实际效果，...
借HSDB来探索HotSpot VM的运行时数据1
08-03
DR版回答是：t1在存Java静态变量的地方, 概念上在JVM的方法区(method area)里t2在Java堆里, 作为Test的一个实例的字段存在t3在J
【已解决】win10 双jdk环境 执行jmap报错：sun.jvm.hotspot.runtime.VMVersionMismatchException:
txjs
03-17 1669
报错信息 sun.jvm.hotspot.runtime.VMVersionMismatchException:Supported versions are 24.80-b11. Target VM is 25.191-b12 排查思路： 根据报错信息可以看出是jvm版本问题。经网上查询说是本机安装多个jdk导致,切换到具体的jdk bin目录下便可以正确执行. 的确，我在widows10环境...
【JVM】【linux】linux上执行jmap命令查看JVM内存使用情况，报错：sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not f...
weixin_30505751的博客
06-26 1844
运行命令： jmap -heap 6709 报错如下： Attaching to process ID 6709, please wait... sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "gHotSpotVMTypes" in any of the known l...
搞定Hotspot-api
weixin_33907511的博客
08-19 103
目的，搞这玩意儿，无非想学习下hotspot中的java对象体系。恩直接上代码吧。 做了一个工程： 待观察类： package hotspot.api.test; /** * hotspot 观察类 * @author * */ public class Wukong { public static int wk_static_i = 777...
找不到或无法加载主类 sun.jvm.hotspot.HSDB
水逆呱的博客
11-17 3415
https://blog.csdn.net/weixin_37152234/article/details/99775593 java -classpath "%JAVA_HOME%/lib/sa-jdi.jar" sun.jvm.hotspot.HSDB 如果出现以下错误，将jdk/jre/bin/sawinbg.dll文件拷到对应目录即可
hotspot虚拟机
最新发布
07-29
3. 内存管理：Hotspot虚拟机使用垃圾回收器来管理内存，自动回收不再使用的对象，减少了手动内存管理的负担。 4. 跨平台性：由于Hotspot虚拟机是Java平台的一部分，它可以在不同操作系统上运行，使得Java程序具有很...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值