CN103530171A - 一种智能卡虚拟机及其实现方法 - Google Patents

Abstract

本发明涉及一种智能卡虚拟机及其实现方法，属于涉及智能卡虚拟机技术领域。本发明公开的智能卡虚拟机，至少包括指令装载器和指令解释器，所述指令装载器，持续地从虚拟机的可执行文件中装载指令，所述指令解释器对装载的指令进行译码，判断出该指令要进行的操作，然后进行指令的分发，跳转到指令对应的操作处，直至所述可执行文件中所有的指令执行结束；其中，可执行文件中存储有指令和指令涉及到的操作数。本发明还公开了一种智能卡虚拟机实现方法。本申请技术方案与现有技术相比更加显得简单而高效。

Description

一种智能卡虚拟机及其实现方法

技术领域

本发明涉及智能卡虚拟机技术领域，特别涉及一种智能卡虚拟机及其实现方法。

背景技术

智能卡（Smart Card）业界还没有标准的高级应用接口，应用开发者需要处理很低级的通信协议、存储管理，和其它由专门的智能卡硬件所要求的琐碎问题。当今流行中的大多数智能卡应用都是从头开发的定制应用，这是一个很费时间的过程；通常要把一个产品推向市场得化一两年的时间。要把软件升级或把应用移植到不同的平台上就特别困难，甚至不可能。因为所开发的智能卡应用只能在专用平台上运行，所以来自于不同服务提供者的应用不能在一张卡片上并存和运行。缺乏互操作性和有限的卡片功能妨碍了智能卡应用的更加广泛的推广。

而虚拟机的出现就是解决智能卡这一问题的有效手段，通过虚拟机屏蔽掉底层平台的不同，达到上层应用开发的简化。JavaCard技术是智能卡上虚拟机的典型应用。在智能卡硬件平台上，通过构建一个软件系统，以支持Java语言下载、运行。Java智能卡继承了Java技术的平台无关性，将硬件和软件分离，简化了应用程序开发，提高了程序移植性。

目前，Java虚拟机（简称JVM）主要包括两个子系统和两个组件：即类装载器子系统、执行引擎子系统、本地方法接口组件和运行时数据区域组件，其架构如图1所示。

其中，类装载器子系统，根据给定的全限定名类名（如java.lang.Object）来装载class文件的内容到运行时数据区域的方法区域。

执行引擎子系统是Java虚拟机实现的核心，执行引擎的行为使用指令集定义。在Java虚拟机中一个字节码流就是一个指令的序列。

本地方法接口组件：与本地方法库交互，是其它编程语言交互的接口。本地方法是把Java程序和非Java语言程序和平台相关的功能结合的有效方式。运行时数据区组件：这个组件就是JVM中的内存。下面对这个部分进行详细介绍。

运行时数据区主要包括五个部分：堆（Heap），方法区域（Method Area），Java栈（Stack），程序计数器（Program Counter），本地方法栈（Native methodstack）。

堆指：Java程序在运行时创建的所有类实或数组都放在同一个堆中。

方法区域指：在Java虚拟机中，装载的.class信息存储在方法区域内存中。

Java栈指：以帧为单位保存线程的运行状态。虚拟机只会直接对Java栈执行两种操作，即以帧为单位的压栈或出栈。

程序计数器：每个运行中的Java程序，每一个线程都有它自己的PC寄存器。PC寄存器的内容总是指向下一条将被执行指令的地址。

本地方法栈：本地方法栈可以通过本地方法接口组件来访问虚拟机的运行时数据区。

目前Class文件的格式如表1所示。

表1为ClassFile表的格式

Java Class文件中的常量池（Constant_pool）包括了与文件中类和接口相关的常量，其中存储了诸如文字字符串、final变量值、类名和方法名的常量。常量池中的许多入口都指向其他的常量池入口，而且class文件中紧随着常量池的许多条目也会指向常量池中的入口在整个class文件中，指示常量池入口在常量池列表中位置的整数索引都指向这些常量池入口。列表中的第一项索引值为1，第二项索引值为2，以此类推。尽管constant_pool列表中没有索引值为0的入口，但缺失的这一入口也被constant_pool_count计数在内。每个常量池入口都从一个长度为一个字节的标志开始，这个标志指出了列表中该位置的常量类型，一旦Java虚拟机获取并解析这个标志，Java虚拟机就会知道在标志后的常量类型是什么。

以上描述的为Java通用虚拟机，在智能卡领域应用的JavaCard虚拟机和上述描述的虚拟机基本是一致的。JCVM是作为两个分立的部分实现的，它由卡外的JavaCard转换器和卡内的JavaCard解释器构成。

JavaCard转换器处理构成一个java包的全部class文件，并将它们转换为一个CAP文件。转换器执行PC环境下Java虚拟机在装载类时所完成的任务。

JavaCard转换器的输入除了Java包对应的class文件外，可能还包括一个或多个export文件；它的输出是一个CAP文件和正被转换包的一个export文件。Export文件用于验证和链接过程，但不被装载到智能卡上，更不被JavaCard解释器直接使用。

但是由于卡上的资源的限制，JavaCard虚拟机和通用的Java虚拟机在一些细节上还是有一些不同，主要体现在以下几个方面：

1）数据类型和值

Java Card虚拟机支持与Java虚拟机相同的两种数据类型：基本类型和引用类型；同样，还有两种相同的值：基本值和引用值。

Java Card虚拟机支持的基本数据类型是numeric类型，boolean类型，和returnAddress类型。numeric类型仅有以下类型组成：

byte，它的值是8位二进制补码整数

short，它的值是16位二进制补码整数

一些Java Card虚拟机实现可能支持额外的整数类型：

int，它的值是32位二进制补码整数

对boolean类型的支持与在Java虚拟机上相同。对引用类型的支持与在Java虚拟机上的支持一致。

2）字

Java Card虚拟机用称为word的抽象存储单元来定义。一个word足够存储byte，short，reference和returnAddress类型的值。两个word则可以存储int类型的值。

3）运行时数据区

Java Card虚拟机仅能支持单线程的执行。Java虚拟机中基于线程复制的任何运行时数据区在Java Card虚拟机中只有一个全局的拷贝。

Java Card虚拟机的堆不被要求有垃圾收集功能。从堆里分配的对象不必回收。

4）上下文

每一个运行在Java Card虚拟机之上的applet与一个执行上下文相关。Java Card虚拟机使用当前框架的上下文以实现内部应用操作的安全策略。

在上下文和包含了applet定义的包之间存在一一对应关系。Java Card运行时环境也拥有自己的上下文。当前执行方法的上下文被称为当前上下文。Java Card虚拟机中的每一个对象都属于一个特定的上下文。这个所属上下文是对象被创建时的当前上下文。

当一个上下文中的方法成功地调用了另一个上下文中对象的方法，JavaCard虚拟机将执行一个上下文切换。之后，被调用的方法的上下文成了当前上下文。当被调用的方法返回时，当前上下文又切换回先前的上下文。

5）框架

Java Card虚拟机框架非常类似于Java虚拟机中的定义。每一个框架有一套局部变量和操作数栈。框架也包含对一个常量池的引用，因为包中所有类的所有常量池都被合并了，这个引用也就是对当前类包的常量池的引用。

每个框架也包括对当前执行方法所在上下文的引用。

6）异常

Java Card虚拟机的异常支持与Java虚拟机的异常支持是同样的。

7）二进制文件格式

这个规范中定义了两种二进制文件格式，用于支持独立于平台的Java卡程序的开发、分布和执行。

在CAP文件中包含了可执行代码，他们可以被下载和安装到支持Java卡技术的设备上。一个CAP文件是通过Java卡的Converter工具生成的，在其中包含了Java类的整个包的转换后的格式。这种文件格式与Java卡虚拟机的关系就象class文件与Java虚拟机的关系。

export文件中包含了Java Card API包的公有连接信息。一个包的export文件当在转换那个包的客户包时使用。

8）指令集

Java卡虚拟机指令集类似于Java虚拟机指令集。一个指令是由一个字节的操作码和0或多个操作数组成的。Java卡虚拟机指令取得-解码-执行的循环的伪代码是和Java虚拟机相同的。多字节的操作数是按照big-endian顺序进行编码的。Java Card虚拟机指令集在很多方面与Java虚拟机的指令集不同。多数差异是由于Java Card虚拟机在数据类型的支持方面有更多的制约。另一个差异的根源在于Java Card虚拟机是计划运行在8位和16位体系结构上的，而Java虚拟机是为32位结构设计的。

CAP文件是JavaCard虚拟机上的可执行文件，其作用相当于普通Java虚拟机中的class文件。一个CAP文件包含了一个Java包中定义的所有类和接口信息。它采用紧缩的数据结构，主要针对小型化设备。在CAP文件定义的每一个组件都具有如下通用的格式：

其中，1字节的tag标识了这个组件的类型，2字节的size表示info数组中的字节数。Tag对应的info数组的内容和格式随组件类型的不同而不同，且都是变长的复杂结构。

有效的tag和它们的值如表4.2所示。

表4.2CAP文件组件tag

组件类型	值
		COMPONENT_Header	1
COMPONENT_Directory	2
		COMPONENT_Applet	3

COMPONENT_Import	4
		COMPONENT_ConstantPool	5
COMPONENT_Class	6
		COMPONENT_Method	7
COMPONENT_StaticField	8
		COMPONENT_ReferenceLocation	9
COMPONENT_Export	10
		COMPONENT_Descriptor	11
COMPONENT_Debug	12

从上表可以看出，CAP文件采用了与class文件类似的分区方式。这里不再赘述。

但是，由于上述JavaCard是由Oracle公司控制，使用者需要向Oracle公司支付大量费用。

并且，现有技术中还存在如下问题：

1、现有技术所采用的二进制文件格式设计比较复杂，无疑给虚拟机添加了额外的执行负担。

2、现有Java虚拟机的每个类都会对应到一个.class文件（Java虚拟机的字节码文件），这些class文件之间有很多冗余信息，需要多占用一定的空间。而虚拟机也需要额外地处理这些冗余信息，造成执行效率低下。

3、现有虚拟机技术面向对象，任何数据信息都以对象的形式组织，而新建一个对象需要大量的内存空间，这对于智能卡来说是一个很致命的缺陷。

4、也是因为面向对象，现有虚拟机的指令集中包含大量额外的对象处理指令，在不需要面向对象的环境里显得多余且使执行效率低下。

5、传统的虚拟机为了高效率回收空间，设计了复杂的垃圾回收机制，往往需要付出相当的性能代价。

6、传统的虚拟机大多支持Java等强类型编程语言，令使用主流脚本语言的网页开发者无所适从。

发明内容

本发明所要解决的技术问题是，提供一种智能卡虚拟机及其实现方法，以便轻量级的虚拟机在智能卡内高效地解析字节码。

为了解决上述技术问题，本发明公开了一种智能卡虚拟机，至少包括指令装载器和指令解释器，其中：

所述指令装载器，持续地从虚拟机的可执行文件中装载指令，所述指令解释器对装载的指令进行译码，判断出该指令要进行的操作，然后进行指令的分发，跳转到指令对应的操作处，直至所述可执行文件中所有的指令执行结束；

其中，可执行文件中存储有指令和指令涉及到的操作数。

可选地，上述智能卡虚拟机中，所述可执行文件为二进制文件。

可选地，上述智能卡虚拟机还包括运行时数据区域组件；

所述运行时数据区域组件至少包括一个栈，一个表，以及一个堆，所述运行时数据区域组件中的表记录所述指令装载器可装载的各种变量类型，引用计数和在堆区存放的偏移地址。

可选地，上述智能卡虚拟机还包括本地方法接口组件：

所述指令解释器判断出指令需要调用的本地方法，然后将指令分发到相应的本地方法接口组件，所述本地方法接口组件对所接收到的指令进行相应的操作并存储操作结果。

可选地，上述智能卡虚拟机中，所述可执行文件中还包括函数变量释放指令，所述函数变量释放指令在所述可执行文件调用的每个函数执行结束后，释放该函数的局部变量。

本发明还公开了一种智能卡虚拟机实现方法，该方法包括：

智能卡虚拟机持续地从可执行文件中装载指令，对所装载的指令进行译码，判断出该指令要进行的操作，然后进行指令的分发，跳转到指令对应的操作处，直至可执行文件中所有的指令执行结束；

其中，可执行文件中存储有指令和指令涉及到的操作数。

可选地，上述方法中，所述可执行文件为二进制文件。

可选地，上述方法中，所述智能卡虚拟机还包括运行时数据区域组件，所述运行时数据区域组件至少包括一个栈，一个表，以及一个堆；

所述智能卡虚拟机通过运行时数据区域组件中的表记录各种变量类型，引用计数和在堆区存放的偏移地址，通过运行时数据区域组件中的堆和栈管理字节码在处理过程中的变量、中间结果及函数调用过程中的信息。

可选地，上述方法中，所述智能卡虚拟机还包括本地方法接口组件：

所述指令解释器判断出指令需要调用的本地方法，然后将指令分发到相应的本地方法接口组件，所述本地方法接口组件对所接收到的指令进行相应的操作并存储操作结果。

可选地，上述方法中，所述可执行文件中还包括函数变量释放指令，所述函数变量释放指令在所述可执行文件调用的每个函数执行结束后，释放该函数的局部变量。

本申请技术方案所提出的二进制可执行文件中的字节码舍弃了class文件中的域、方法、属性、接口等的分区方式，而将各种类型的数据直接放在指令之中，通过编码方式的不同而区分各自的属性，函数间直接通过计算好的偏移地址而实现跳转，调用哪个本地方法也在字节码中直接体现。因此本申请技术方案与现有技术相比更加显得简单而高效。另外，本申请技术方案不需要装载各类数据，一条指令已包含了所有的执行信息，故取指、执行的操作更加便捷。

附图说明

图1为传统Java虚拟机的架构示意图；

图2为本实施例中智能卡虚拟机的架构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文将结合附图对本发明技术方案作进一步详细说明。需要说明的是，在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

实施例1

本实施例介绍一种智能卡虚拟机，至少包括指令装载器和指令解释器。

指令装载器，持续地从虚拟机的可执行文件中装载指令，指令解译器对装载的指令进行译码，判断出该指令要进行的操作，然后进行指令的分发，跳转到指令对应的操作处，直至所有的指令执行结束。其中，可执行文件中存储有指令和指令涉及到的操作数。

本虚拟机定义的内存管理模式简单高效，优选地，还包括运行时数据区域组件，其可以只有一个栈，一个表，以及一个堆。该智能卡虚拟机可通过运行时数据区域组件中的表来记录各种变量类型（即能够装载的数据类型，如布尔型、整型、字符串型、数组型、NULL），引用计数和在堆区存放的偏移地址。通过堆栈来管理字节码在处理过程中的变量、中间结果及函数调用过程中需要保存的一些信息，例如当前的执行字节码流的指针等等。

下面以一条加法操作的指令为例，说明上述运行时数据区域组件中各部分的功能。例如加法操作指令的形式为add op1，op2，其在.p文件的编码可能是D48978（此为简化说明，实际上.p文件会对变量进行编码，不会直接将89和78体现在指令中），含义为将89和78相加。首先，指令装载器从.p文件中读取到D4这个指令，由指令解释器将这个指令翻译成加法操作的函数，进入加法操作后，首先会在运行时数据区中的表里创建一个存储单元，用于存储后续的计算结果，然后处理加法的操作会从.p文件中读取两个操作数即89、78，然后将计算结果压入运行时数据区的栈里，供下一条指令或返回结果使用。不过，要说明的是，此加法操作指令没有用到运行时数据区组件的堆，堆的作用是当指令处理时需要动态的内存时，需要从堆中分配。

另外，在指令执行过程中，还将与本地方法库进行交互。此时智能卡虚拟机的结构如图2所示，还包括本地方法接口组件。其中，本地方法接口是在虚拟机内部实现的一系列函数功能的总称，主要提供给应用开发者使用，这样做的好处的是能够提高代码的执行速度。而本地方法接口组件与智能卡虚拟机的其他部分的工作过程如下：例如有一本地函数subStr（String a，intstart，int length），该函数的功能是求一个字符串的子集。当应用开发者在应用的开发的过程调用了这个方法，在生成的可执行文件（.p文件）中就会体现这样一个调用，智能卡虚拟机执行到调用处时就会发现这是一个本地方法，那么就在虚拟机内部的方法列表中查找这个函数的对应位置，完成相应的功能。具体地，指令装载器和指令解释器能够正确判断需要调用的本地方法，并跳转到相应的本地方法接口组件，且运行时，本地方法接口组件会对本地方法执行过程结果进行相应的存储。

下面结合具体应用场景，说明上述虚拟机实现.p文件的应用的过程。

智能卡接收到.p格式的应用文件时，智能卡操作系统启动虚拟机，虚拟机首先进行初始化操作，具体包括内存的分配、数据结构的创建等操作。当虚拟机的初始化操作结束以后，虚拟机启动指令装载器，从.p文件中装载指令，指令装载结束后，虚拟机中的指令解释器将根据读取的指令码匹配到对应处理函数里，在处理函数里，根据指令的特点，从.p文件中读取相应的操作数（如果没有就不用读取），根据指令处理的操作数类型（即操作数的格式），将.p文件中读取的数据转化为对应的数据格式，转换结束后，根据指令应该完成的功能，执行相应的操作，当一条指令结束，虚拟机继续读取.p文件中的指令，进行解析，执行相应的操作。直到读取完.p文件中的所有指令。

优选地，.p文件中还包括有函数变量释放指令，以便.p文件调用的每个函数执行结束后，释放该函数里的局部变量，即释放占用的资源。当整个.p文件读取结束，最后由卡片操作系统结束虚拟机。卡片操作系统将接管卡片流程，继续执行。

实施例2

本实施例介绍一种智能卡虚拟机实现方法，包括如下操作：

智能卡虚拟机持续地从可执行文件中装载指令，对所装载的指令进行译码，判断出该指令要进行的操作，然后进行指令的分发，跳转到指令对应的操作处，直至可执行文件中所有的指令执行结束；

其中，可执行文件中存储有指令和指令涉及到的操作数。

在上述方法的基础上，智能卡虚拟机还可以包括运行时数据区域组件，所述运行时数据区域组件至少包括一个栈，一个表，以及一个堆；

智能卡虚拟机通过运行时数据区域组件中的表记录各种变量类型，引用计数和在堆区存放的偏移地址，通过运行时数据区域组件中的堆和栈管理字节码在处理过程中的变量、中间结果及函数调用过程中的信息。

另外，智能卡虚拟机还可以包括本地方法接口组件：

所述指令解释器判断出指令需要调用的本地方法，然后将指令分发到相应的本地方法接口组件，所述本地方法接口组件对所接收到的指令进行相应的操作并存储操作结果。

优选地，可执行文件.p文件中还包括有函数变量释放指令，其在可执行文件调用的每个函数执行结束后，释放该函数的局部变量，从而释放不再使用的内存空间。

需要说明的是，本实施例中的可执行文件为二进制文件，可简述为.p文件。该二进制可执行文件中的字节码舍弃了class文件中的域、方法、属性、接口等的分区方式，而将各种类型的数据直接放在指令之中，通过编码方式的不同而区分各自的属性，函数间直接通过计算好的偏移地址而实现跳转，调用哪个本地方法也在字节码中直接体现。

从上述实施例可以看出，本申请技术方案所提出的二进制可执行文件中的字节码舍弃了class文件中的域、方法、属性、接口等的分区方式，而将各种类型的数据直接放在指令之中，通过编码方式的不同而区分各自的属性，函数间直接通过计算好的偏移地址而实现跳转，调用哪个本地方法也在字节码中直接体现。因此相对于JVM class文件中的多个分区和需要不断地计算和查找各种操作数信息，本申请技术方案所提出的二进制可执行文件更加显得简单而高效；又由于本申请技术方案不需要装载各类数据，一条指令已包含了所有的执行信息，故取指、执行的操作更加便捷。

同时，相对于Java虚拟机来说，每个类都会对应到一个.class文件（即一个函数对应一个.class文件），因此多个class文件之间有很多冗余信息，需要多占用一定的空间；而虚拟机也需要额外地处理这些冗余信息，造成执行效率低下。而本申请技术方案中提供的二进制可执行.p文件可对应多个函数，这样不会出现重复的信息，不仅节省了存储空间，也方便了在不同函数间的跳转。并且，从上述实施例中可以看出，本申请技术方案中智能卡虚拟机只在执行.p文件时启动，.p文件执行结束后智能卡虚拟机即会退出。执行下一个.p文件时，智能卡虚拟机再次启动。这样的操作是考虑到智能卡上还有很多操作不通过虚拟机，而智能卡是单线程的。而且，这样的操作也可以节省空间，因为智能卡虚拟机启动后就要为其分配空间，即使还没开始执行字节码，也要分配空间。还要说明的是，当执行的.p文件的应用内置在智能卡操作系统中时，则无需启动本申请的智能卡虚拟机进行操作了。

另外，当智能卡虚拟机执行的是非.p形式存在的应用时，则无需启动本申请的智能卡虚拟机进行操作了。也就是说，只要是.p文件形式存在的应用，必然会启动本申请的智能卡虚拟机，而且只有是执行.p文件形式的应用才能启动智能卡虚拟机。

而且，本申请技术方案本着最小但最有效原则，为了避免对象处理指令，而采用了最精简而完备的指令集，最大程度减小代码量和复杂度，最大限度发挥了智能卡的性能。

另外.现有虚拟机技术面向对象，任何操作数都以对象组织，而新建一个对象需要大量的内存空间，这对于智能卡来说是一个很致命的缺陷。而本申请技术方案所提出的二进制可执行.p文件的格式令智能卡虚拟机可采用面向过程处理，即取缔了对象这一结构单位，从而也就节省了大量的内存空间并提高了智能卡虚拟机的执行效率。

一般智能卡虚拟机为了高效率回收空间，设计有复杂的垃圾回收机制，往往还需要付出相当的性能代价。而本申请中的智能卡虚拟机则不存在这样的问题，其能做到在使用结束后立即释放，即执行智能卡虚拟机的每个函数退出时，会自动生成针对该函数里定义的局部变量的释放指令，从而释放不再使用的内存，也可以降低代码的复杂度。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

以上所述，仅为本发明的较佳实例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种智能卡虚拟机，其特征在于，至少包括指令装载器和指令解释器，其中：

所述指令装载器，持续地从虚拟机的可执行文件中装载指令，所述指令解释器对装载的指令进行译码，判断出该指令要进行的操作，然后进行指令的分发，跳转到指令对应的操作处，直至所述可执行文件中所有的指令执行结束；

其中，可执行文件中存储有指令和指令涉及到的操作数。

2.如权利要求1所述的智能卡虚拟机，其特征在于，

所述可执行文件为二进制文件。

3.如权利要求1或2所述的智能卡虚拟机，其特征在于，还包括运行时数据区域组件；

所述运行时数据区域组件至少包括一个栈，一个表，以及一个堆，所述运行时数据区域组件中的表记录所述指令装载器可装载的各种变量类型，引用计数和在堆区存放的偏移地址。

4.如权利要求1或2所述的智能卡虚拟机，其特征在于，还包括本地方法接口组件：

所述指令解释器判断出指令需要调用的本地方法，然后将指令分发到相应的本地方法接口组件，所述本地方法接口组件对所接收到的指令进行相应的操作并存储操作结果。

5.如权利要求3所述的智能卡虚拟机，其特征在于，

所述可执行文件中还包括函数变量释放指令，所述函数变量释放指令在所述可执行文件调用的每个函数执行结束后，释放该函数的局部变量。

6.一种智能卡虚拟机实现方法，其特征在于，该方法包括：

智能卡虚拟机持续地从可执行文件中装载指令，对所装载的指令进行译码，判断出该指令要进行的操作，然后进行指令的分发，跳转到指令对应的操作处，直至可执行文件中所有的指令执行结束；

其中，可执行文件中存储有指令和指令涉及到的操作数。

7.如权利要求6所述的方法，其特征在于，

所述可执行文件为二进制文件。

8.如权利要求6或7所述的方法，其特征在于，所述智能卡虚拟机还包括运行时数据区域组件，所述运行时数据区域组件至少包括一个栈，一个表，以及一个堆；

所述智能卡虚拟机通过运行时数据区域组件中的表记录各种变量类型，引用计数和在堆区存放的偏移地址，通过运行时数据区域组件中的堆和栈管理字节码在处理过程中的变量、中间结果及函数调用过程中的信息。

9.如权利要求6或7所述的方法，其特征在于，所述智能卡虚拟机还包括本地方法接口组件：

所述指令解释器判断出指令需要调用的本地方法，然后将指令分发到相应的本地方法接口组件，所述本地方法接口组件对所接收到的指令进行相应的操作并存储操作结果。

10.如权利要求6或7所述的方法，其特征在于，

所述可执行文件中还包括函数变量释放指令，所述函数变量释放指令在所述可执行文件调用的每个函数执行结束后，释放该函数的局部变量。

Images