cvm java,关于嵌入式Java虚拟机 --- CVM

Root Data结构体设计CVM的一个标准就是可以重新启动，无论这个宿主操作系统是否支持进程。抛开进程的支持，来完成冲洗启动虚拟机的过程需要我们能够释放在启动CVM过程中所有malloc'ed 的内存。为了使之变得简单(而且，不论怎么说这也算的上是一个好习惯) ，我们会确保所有的数据都是可以从内存中的单根树的根节点出发找到。这个根节点结构体是 CVMglobals ，它位于上图中的左边。你可以在 globals.h here (也可以在这个文件中找到 CVMGlobalState )中找到VMglobals 的定义。仔细看看 CVMglobals，你会发现它是所有系统全局数据结构的集合体。把所有的全局变量用一个数据结构记录下来，也可以把这些值恢复为初始状态变的较为简单。比如是通过 memsetting 把所有的字节置为0。 (当然，这需要在我们正确的完成了子树的清理工作后进行)。 GC 以及 Java 堆从全局的变量中，可以找到含有或者持有GC配置以及管理信息的数据结构。(CVMglobals.gc). 从这里，最终你可以获得Java堆。 CVM 有一个可以嵌入的 GC 结构。这里的可嵌入值得是编译时的可嵌入。者允许试验性质的GC可以进行试验而变得稳定。目前，唯一的具有产品质量的GC是 generational GC (见 here 和 here 相关的 GC 标准实现文件)。所有的Java 对象, 也就是所有继承自 java.lang.Object, 都是从Java 堆分配的内存。唯一的例外是那些预链接的(ROMized) java对象。这些数据保存在全局数据中。Java堆其自身是从C堆中分配的。所有的其它的数据结构要么是全局数据(也就是.bss段, .data段，或者其它类似的)，要么就是从C堆中分配的。 JIT 与编译的代码 CVMglobals 同样维护着JIT的配置和管理记录。 (CVMglobals.jit)。遍历树，你最终可以找到 JIT code buffer (或者叫做代码缓存code cache).。这里的代码缓存目前是固定大小的。(但是在运行时是可以配置的) 这块内存是在虚拟机启动时分配的。一旦分配了内存，内存的大小就不可以变更了。但一个Java方法被JIT编译了，那么JIT就会生成比特数据(就是提到的 compiled method) 缓存到JIT的代码缓存中。编译过的方法的元数据 (由JIT生成的) 同样也活储存在代码缓存中.。因此，代码缓存的大小就要规定出来，以确定有多少个方法可以被编译。 Java 对象与类当一个类文件被加载到内存中以后，它的内容被解析并组织成了优化的数据结构。他被分配到了C堆里面。这个数据结构是 CVMClassBlock，它保存了这个类的所有的元数据。源数据包括了 constantpool, 类属性，类字段，方法的信息和字节码等等。对于每一个 CVMClassBlock，都有一个 java.lang.Class 实例与之对应，这个实例也是从Java 堆中分配的。一旦一个类被正确的加载后，类与Class 的实例会议之成对的存在。 classblock 会有一个指向class对象的引用，反之亦然。当一个类被卸载后者两者都回被释放掉。每一个CVM中的对象都有两个字的头。第一个字通常是一个指向 classblock 的指针。然而，这里的头信息对于Java 代码来说是不可见的。只能在CVM的C代码里使用。注意：因为 java.lang.Class 继承了java.lang.Object， Class类的实例也将有这两个字的头信息。 Key files to look at are objects.h and classes.h. See here for the files. Java 线程为了能执行任何事，虚拟机必须支持线程。每一个线程都表现为 CVMExecEnv (也叫做 ee).。在虚拟机中，ee本质上是一个线程的标识符。所有的线程操作都需要当前线程的ee作为参数使用。见 interpreter.h here 和interpreter.c here. 在ee和java.lang.Thread 实例之间有一对一的映射关系。一旦一个线程被正确的初始化以后，这两者将一直成堆的存在。同样，ee和JNIEnv.之间也有一一对应的关系。 JNIEnv 是作为ee的一个成员出现的。 ee 与 JNIEnv地址之间的映射基本上只会在偏移量调整的时候用到。所有的 ee都已经被连接成一条链表了，链表的头是 CVMglobals.threadList。主线程的ee是CVMglobals的成员。其它的都是 malloc'ed。系统的互斥体操控虚拟机中的线程需要实现同步，这在虚拟机中的其它的子系统和资源中也是一样的。同步操作通常都是由 CVMSysMutex 完成的。(见sync.h here 和sync.c here)。There are several sysMutexes allocated at VM boot time. These mutexes are not visible to Java code, only VM C code. They are only used by VM code, not Java code. Each sysMutex has a dedicated purpose (e.g. the CVMglobals.threadLock is for synchronizing the thread operations), and is ranked. In order to prevent deadlock, sysMutexes can only be locked in increasing rank order. When CVM is built with assertions enabled, this rank order will be asserted. Java Execution Stack Any thread of execution must have an execution stack. In CVM, each Java thread has 2 physical stacks: a native stack, and a Java stack. The native stack is the one that is allocated by the OS, and is used for C code execution. It holds the activation records (i.e. stack frames) of native code, and VM code including the interpreter loop function. It also holds activation frames for JIT compiled code (with a twist). The Java stack (also known as the interpreter stack) is used to hold the activation records of Java methods. For each Java method that is executed, a frame will be pushed on this stack. Stack and frame data structures are defined in stacks.h here and stacks.c here . If you dump a trace of the native stack when executing several Java methods, you will see stack frames for C code and the interpreter loop. If you dump a trace of the Java stack, you will only see stack frames for the Java methods that have been invoked. If you have a native method in the invocation chain, you will see a stack frame in both the native and Java stack. This is because the native method is both a C function and a Java method at the same time. GC Roots and Root Stacks In GC terms, CVM is called an exact VM. This means that at the time of GC, we will be able to know definitely where all the object pointers are in the system. This is in contrast with conservative GC systems which requires you to guess whether some piece of memory contains an object pointer or just some random data that resembles an object pointer. All reachable (and therefore live) objects in the VM can be found by tracing this tree (or trees) of object references called the GC root tree. The tree starts from a root reference. These root references are essentially globals, and are usually stored in data structures called root stacks. An example of this is CVMglobals.globalRoots. Strictly speaking, these data structures need not be stacks. They are actually used as lists. However, our Java stack data structures have properties that fulfills the needs of GC root stacks nicely, and doesn't require us to write additional code (good for code efficiency). So, we just use the stacks. If an object cannot be found by tracing the root trees, then that object is unreachable and therefore can be reclaimed by the GC. Note that in traversing a tree, at any point in the traversal, a node can be the root of a new subtree. Hence, the term root or GC root is sometimes used to refer to object pointers / references that are found alone the way in a root scan. GC roots can be found in the root stacks, in thread execution stacks, and in object and class fields. the End That should be enough to give you an overall idea of how the major data structures are laid out in CVM. Note: most of the things I told you above is meant to give you a good conceptual model of the lay of the land. In practice, there will be exceptions in some cases for various reasons. Sometimes, these exceptions will break the rules. Other times, they are like extension to the rules. To keep things simple, I left out the exceptions. I may get into those when I talk about each subsystem and/or data structure specifically. In the above, I also left out many juicy details like ... why allocated a data structure from the C heap vs the Java heap. I'll leave that for subequent discussions. So, in the next few days (or weeks), I will zoom in on the CVM subsystems and/or data structures (one at a time), and talk about them in detail. This will include mechanical details as well as design philosophies for why things are the way they are (when relevant, of course). Again, feel free to ask questions or make requests for topics. I will try to accommodate as much as I can. Have a nice day. :-)

cvm java,关于嵌入式Java虚拟机 --- CVM相关推荐

cvm java_移植JAVA虚拟机CVM到ARM平台（收藏）
J2ME CDC(Connected Device Configuration,连接式设备配置集)使用CVM,面向那些具有更强计算能力的嵌入式设备,包含了Java类库的核心部分,是应用Java技术在嵌 ...
java cvm_java虚拟机CVM到ARM平台
J2ME CDC(Connected Device Configuration,连接式设备配置集)使用CVM,面向那些具有更强计算能力的嵌入式设备,包含了Java类库的核心部分,是应用Java技术在嵌 ...
java对嵌入式_Java用于嵌入式系统的优点
Java用于嵌入式系统的优点与个人计算机这样的通用计算机系统不同,嵌入式系统通常执行的是带有特定要求的预先定义的任务.yjbys小编下面为你整理了关于Java用于嵌入式系统的优点,希望对你有所帮助. ...
java 教程嵌入式,嵌入式狗的 JAVA 入门笔记·1
嵌入式狗的JAVA之路.记录下学习过程,方便以后翻看了解C C++基础,应该学习不会慢~~~~吧~,~ 名词熟悉 JVM: Java Virtual Machine JAVA虚拟机 JAVA工作原理: ...
Java DB嵌入式模式
Java DB是基于Java编程语言和SQL的关系数据库管理系统. 这是Apache软件基金会的开源Derby项目的Oracle版本. Java SE 7 SDK中包含Java DB. Java DB ...
Java用于嵌入式系统的优点和局限
越是高级的语言,其编译和运行的系统开销就越大,应用程序也越大,运行越慢.因此一般来说,编程人员都会首选汇编语言和C语言,然后才会考虑C++语言或Java语言. 但是随着不断增长的市场需求,很多嵌入式设 ...
java语言发展史，虚拟机的安装与配置
1. 计算机基础 1.1. 计算机电子计算机,俗称电脑,是一种能够按照程序运行,自动.高速处理海量数据的现代化智能电子设备.由硬件和软件所组成,没有安装任何软件的计算机称为裸机. 1.2. 硬件和 ...
【Java】实战Java虚拟机之五“开启JIT编译”
今天开始实战Java虚拟机之五"开启JIT编译" 总计有5个系列实战Java虚拟机之一"堆溢出处理" 实战Java虚拟机之二"虚拟机的工作模式&qu ...
嵌入式java基准测试_Java正则表达式库基准测试– 2015年
嵌入式java基准测试在尝试使Java在计算机语言基准游戏的regexdna挑战中排名第一时,我正在研究Java正则表达式库的性能. 我可以找到的最新网站是2010年的tusker.org .因此, ...

cvm java,关于嵌入式Java虚拟机 --- CVM

cvm java,关于嵌入式Java虚拟机 --- CVM相关推荐

最新文章

热门文章