群组首页 → 编程语言 → 高级语言虚拟机 → 论坛
发表回复

[讨论] java_main的汇编入口在哪里

gaolingep 2013-05-07

谢谢。

instanceOopDesc 以及oopDesc 的源码

class instanceOopDesc : public oopDesc

 

class oopDesc {
  friend class VMStructs;
private:
  volatile markOop  _mark;
  union _metadata {
    wideKlassOop    _klass;
    narrowOop       _compressed_klass;
  } _metadata;

  // Fast access to barrier set.  Must be initialized.
  static BarrierSet* _bs;

public:
  enum ConcSafeType {
    IsUnsafeConc = false,
    IsSafeConc   = true
  };

 

回答MR.R 关于jdk版本的问题
我在win7 x86下编译了jvm
E:\WorkSpace\JVM\openjdk\build\windows-i586\j2sdk-image\bin\java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-gaoling_2013_04_15_00_11-b00)
OpenJDK Client VM (build 21.0-b17, mixed mode)

在win7 x64下用vs2012打开hotspot做调试（x64+vs2012实在编译不过去）
E:\WorkSpace\JVM\openjdk\hotspot\build\vs-i486\compiler1\debug\hotspot.exe -version
Using java runtime at: E:\WorkSpace\JVM\openjdk\build\windows-i586\j2sdk-image\jre
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-gaoling_2013_04_15_00_11-b00)
OpenJDK Client VM (build 21.0-b17-internal-debug, mixed mode)

 
RednaxelaFX 2013-05-09
OK, good. 这样就可以回答之前的问题了。
HotSpot VM里的对象布局会受平台和参数的影响，必须要知道您实际用的是什么版本才可以解释您看到的内存里的东西是什么意思。

前面您贴的内存数据，实际上是这样的： 
instanceOopDesc for String "111111111111" (size = 24)
0x0F2310A0  01 00 00 00  ;; oopDesc::_mark            = 0x00000001
0x0F2310A4  58 77 18 1f  ;; oopDesc::_metadata._klass = 0x1F187758 (-> klassOopDesc for java.lang.String)
0x0F2310A8  b8 10 23 0f  ;; java.lang.String.value    = 0x0F2310B8 (-> typeArrayOopDesc for char[])
0x0F2310AC  00 00 00 00  ;; java.lang.String.offset   = 0
0x0F2310B0  0c 00 00 00  ;; java.lang.String.count    = 12
0x0F2310B4  00 00 00 00  ;; java.lang.String.hash     = 0

typeArrayOopDesc for char[12] (size = 40)
0x0F2310B8  01 00 00 00  ;; oopDesc::_mark            = 0x00000001
0x0F2310BC  a0 03 18 1f  ;; oopDesc::_metadata._klass = 0x1F1803A0 (-> klassOopDesc for char[])
0x0F2310C0  0c 00 00 00  ;; arrayOopDesc::_length     = 12
0x0F2310C4  31 00 31 00  ;; [0] = '1', [1] = '1'
0x0F2310C8  31 00 31 00  ;; [2] = '1', [3] = '1'
0x0F2310CC  31 00 31 00  ;; [4] = '1', [5] = '1'
0x0F2310D0  31 00 31 00  ;; [6] = '1', [7] = '1'
0x0F2310D4  31 00 31 00  ;; [8] = '1', [9] = '1'
0x0F2310D8  31 00 31 00  ;; [10] = '1', [11] = '1'
0x0F2310DC  00 00 00 00  ;; (padding: 4 bytes)


Java对象布局的计算在ClassFileParser里，其中只有对象头的部分是在C++里显式声明的（也就是oopDesc的部分），而后面Java字段的布局都是HotSpot VM自己计算的，没有在C++里直接声明。这是实现VM的常见技巧。

关于32位HotSpot VM里java.lang.String的布局，我正好以前在几个地方都提到过，
借助HotSpot SA来一窥PermGen上的对象
分享：Java 程序的编译，加载 和 执行

BarrierSet* _bs是instanceOopDesc的静态变量，不包含在其实例里。
huangriyan 2014-08-28
generate_call_stub、generate_normal_entry这种方法什么时候调用？他们 在 generate 的时候已经执行了 __ pc() 到 return address 这段代码了，之后再call address ，岂不是执行了两次，如 generate_normal_entry 内 ，address entry_point = __ pc(); 到 return entry_point 已经在 generate_normal_entry 的时候执行一次了，再在 call_stub 中 call 一次，岂不是在执行了两次这段代码
cheney_love 2014-09-16
huangriyan 写道
generate_call_stub、generate_normal_entry这种方法什么时候调用？他们 在 generate 的时候已经执行了 __ pc() 到 return address 这段代码了，之后再call address ，岂不是执行了两次，如 generate_normal_entry 内 ，address entry_point = __ pc(); 到 return entry_point 已经在 generate_normal_entry 的时候执行一次了，再在 call_stub 中 call 一次，岂不是在执行了两次这段代码

jvm 启动的时候调用
发表回复
Global site tag (gtag.js) - Google Analytics