Dud*_*lul 5 javascript c# python java vm-implementation
我有一种感觉,我会问一个"愚蠢"的问题,但我必须问......
我有2个虚拟机.
我想将一个对象的实例从一个复制到另一个,
是否可以将表示此对象的位复制到VM的堆中,将其发送到另一个VM,就像另一个VM只需要在其内存中分配位并在其堆栈中添加一个引用到此内存插槽一样. .?
目前,为了做这样的事情,我们序列化对象并对其进行反序列化,这比仅仅复制实例效率低(计算方面)......解析是一种计算浪费......
JS序列化示例:每个VM都是V8(JavaScript)的一个实例,其中一种方法是将对象转换为JSON(JSON.stringify),向其发送一些如何获取字符串并将其转换回对象的其他VM(例如,var myObject = eval('(' + myJSONtext + ')');)..(JavaScript只是一个例子,这是某种序列化)
让我们暂时忽略一个天真的假设,即你可以轻松地在多个虚拟机上概括这个问题.任何构建这样的机制的尝试都将在很大程度上取决于您构建机制的VM的实现细节.
以下是为什么不这样做的几个原因:
内核表示通常不能跨架构移植.如果我在不知道其结构的情况下从SPARC机器上的VM向x86机器上的VM发送"对象",则该对象在另一侧看起来会损坏.
该对象不一定存在于两台机器上的相同内存位置,因此对象内的内部指针需要在到达第二个VM后进行修补.这也需要对象结构的内部知识.
该对象可能包含对其他对象的引用,因此复制对象意味着复制对象树,并且通常也不是非循环树.您最终构建的代码看起来非常像序列化库,以便可靠地执行此操作.
对象通常保留在无法通过计算机可靠传输的本机资源(如文件句柄和套接字)上.
在许多虚拟机中,数据(您尝试复制的对象)和元数据(例如,您尝试复制的对象的类)之间存在差异.在这些类型的VM中,即使您可以无损地逐位复制对象,也可能依赖于远程端不存在的一堆元数据.逐位复制元数据也很棘手,因为许多虚拟机使用实现技术(例如内部字符串或内存映射目标代码的全局池)使数据本身不可移植.您最终可能会得到比您想要的更多的元数据(例如,在.net中,您可以打包并在某处发送的最小元数据单元通常是程序集).
内核表示通常在同一VM的不同版本之间不可移植,并且不包含可用于修补数据的内部版本信息.
内核表示包含许多不需要复制的东西(例如内联缓存,垃圾收集信息).复制这些东西会很浪费,而另一方面的信息甚至可能都不合理.
基本上,为了可靠地执行此操作,您最终会构建世界上最笨拙且不可靠的序列化库,并且在修复因天真复制时会破坏的许多内容时,简单内存副本的性能提升会丢失.
因此,这些机制往往不存在.
这个规则有一个很大的例外:基于映像的虚拟机(例如许多smalltalk和自我虚拟机)是围绕虚拟机状态存在于"图像"中的想法构建的,该"图像"可以在机器之间复制,移动等.通常会带来很大的性能成本.
| 归档时间: |
|
| 查看次数: |
352 次 |
| 最近记录: |