【总目录/源代码】:https://blog.csdn.net/qq_40636117/article/details/94383044
【上一篇】:https://blog.csdn.net/qq_40636117/article/details/94654292
解析完属性池后,下一步就是去实现jvm的RunTimeDataArea,也就是运行数据区了。不过要想让jvm运行起来,还得需要方法表里面的数据(比如方法Code属性的指令,局部变量)。
本来就因为解析方、字段表属性太麻烦打算绕过去,现在又绕回来了。
一、属性格式
上次解析属性池的时候,我们知道方法,字段表的格式是这样的:
u1:无符号1字节数据 u2:无符号2字节数据 u4:无符号4字节数据
//属性
typedef struct AttrInfo{
u2 nameIndex; //属性名称索引
u4 len; //属性内容数组大小
u1* infos; //属性内容数组
}AttrInfo;
字段/方法结构
//u1:无符号8位数据 u2:无符号16位数据
typedef struct MemberInfo{
u2 accessFlag; //访问符
u2 nameIndex; //名称索引
u2 desIndex; //描述索引
u2 attrCount; //属性数组大小
AttrInfo* attrInfos; //属性数组(其中方法里面这里存放着方法体)
}MemberInfo;
其中方法,字段的属性就存放在attrInfos里面。这个attrInfos结构可不是像上面那么简单,就nameIndex,len和infos这三个属性,而是有如下种类。
1.Code:代码属性。存放方法的字节码指令,局部变量等信息,Code甚至还有自己的属性。是最复杂的一个属性
2.Exceptions:异常属性,存放异常信息(和Code中自带的异常属性不同)
3.Deprecate:废弃属性。记录类一些废弃的方法
4.Synthetic:表明是由编译器生成
5.sourceFile:用于记录生成这个Class文件的源码文件名称
6.ConstantValue:通知虚拟机自动为静态变量赋值(即标明static修饰的变量)
7.LineNumberTable:用于描述Java源码的行号与字节码行号之间的对应关系
8.LocalVariableTable:用于描述栈帧中局部变量表中的变量与Java源码中定义的变量之间的关系
9.Other:其他不明属性
把这些属性结构列举出来过于繁琐,如果想知道具体信息可以参见这个博客:https://www.cnblogs.com/timlong/p/8143839.html
由于这些属性结构第1,2个变量都是nameIndex(名称索引)和Len(属性占位大小)
所以我自定义了Other属性,其结构为
Other{
u2 nameIndex;
u4 len;
u1 chars[len]
}
将前8种属性一一解析出来,将其他不明属性统统归类为Other,就发生jvm读取到不明属性时无法解析,影响后面的局面了。
二、如何存放属性
很明显,我们解析Code,Exceptions等属性后,是不能放在attrInfos里存放的。我听说C++里面有类也有继承,但不熟悉,不敢动不敢动。于是直接把这些属性作为MemberInfo的一部分。
MemberInfo里面属性个数用2字节存储,我也不敢保证每个属性最多1个(虽然测试了不少类,除了Other以外,没见过同一个属性个数超过2个的),那就当每个属性有多个好了。
对此,我们可以vector或数组存储相同类型的属性
前者的好处是功能强大,较为节省空间(没法确定某种属性个数,数组就得开得大),坏处就是运行时间慢
后者好处是运行时间块,但是较为浪费空间。
比较了很久,我选择了后者,即用数组。因为解析多个类发现,属性个数其实还是挺少的,也浪费不到哪里去。
出于尽可能节省空间,我用了如下方法:
int s=属性总个数
每个类型属性的个数=0
for(int i=0;i<s;++i){
检测到某类型
1.如果该类型属性个数=0:分配大小为s的数组
2.将该类型存放到该类型的数组。s--
}
这种算法的特点不言而喻,属性类型越少越节省空间
好在大多数方法表就一个Code属性,最多再加上一个Exceptions属性,还是比较节省空间的。
三、识别属性类型
由之前文章知道,常量池常量类型由jvm固定死了。1就代表utf8,3就代表Integer。
但是属性类型却自由得多。属性有一个nameIndex变量(二字节),通过这个变量到常量池寻找出的数据就是这个属性的类型
比如某个属性的nameIndex=9,而常量池下标为9的常量是一个内容为“Code”的utf8类型数据,
那么这个属性名称就是Code。
看来要是你开心,也可以自己瞎几把定义一个属性了。
所以这也是为啥属性开始的两个属性为nameIndex(2字节,表示属性类型名称)和Len(4字节,表示属性字节数),
我要自定义Other这个结构体,存放杂七杂八的数据了。
不然真的无法解析下去啊。
由于utf8用unsigned char数组存放,要是想要识别属性类型的话,string现成的方法怕是用不了了,得把字符数组里面的内容一个个取出来判断,有点麻烦。
所以我用了一个简单粗暴的办法:将字符数组前4个元素相加。
这个方法有很大的风险,第一如果属性名的字符小于4,会出现不可预料的后果,第二如果两个属性字符数组前4个元素相加的值相同,就会产生混淆,解析直接出错。
第二个错误实际上也确实发生了。
属性SourceFile的前四个字符 'S'+'o'+'u'+'r' 相加的值为425
属性RuntimeVisibleAnnotations前四个字符 'R'+'u'+'n'+t'也是425
这给我敲响了一个警钟,不过我还是懒,就先这样吧。
四、解析属性
解析属性的工作比较庞杂,因为属性比较多,属性的内容也不少,一不小心写错一点点,直接GG
我先用Other存放所有的属性,然后逐步将Other出去,达到解析属性的目的。其中Code属性解析起来最烦。
解析属性没什么值得说的,佛系写了几天,终于完工了。
测试: