百科问答小站 logo
百科问答小站 font logo



华为方舟编译器 Runtime 已经开源,从技术角度如何评价其架构和实现? 第1页

  

user avatar   wang-peng-cheng-63-31 网友的相关建议: 
      

方舟目前已有的组件,包含孵化器(一个毫无感情的记录机器):

  • 前端
    • C
    • Java,两个实现:1) jbc2mpl,Java字节码前端;2) dex2mpl,dalvik字节码前端
    • Open64的WHIRL IR
    • JS(未开源,可能working in progress)
  • 优化:常规优化都有了,地方太小写不下
  • 后端:
    • AArch64
    • ARM32(未开源)
    • RISC-V
    • MapleEngine,提供Maple IR的Interpreter
  • 调试器
    • 基于GDB的扩展
      • 支持调试C
      • 支持调试Java
      • JS待支持
  • Runtime(这个比较难分类了)
    • Java
      • Android(AArch64)
      • OpenJDK

Sorry这么久才来填坑。

开源出来的方舟目前已经可以实现基于libcore或者OpenJDK运行静态化编译后的Java程序了,不过因为缺少apk编译的程序、魔改后的zygote(mygote)以及可能涉及的Android Runtime相关的修改,目前不能自己编译运行安卓程序。不过如我之前的分析一样,方舟已经可以编译部分第三方应用了,只是华为扣扣嗖嗖一直不全部开源出来(开源的东西是基于Maple的Java静态化,不涉及Android相关的修改)。如果可以的话,华为完全可以把这些实现捐献给AOSP的。

方舟在安卓上的实现,目前应该是比较成熟了,但估计确实存在很多问题(例如代码膨胀、热更新方案、兼容性等等)。不过方舟的目的并不是替换整个安卓运行时(我查了当时的宣发,如果我没理解错的话,当时说的是替换ART),而是将Java静态化编译,消除JNI,并且将内存管理方式替换为RC为主、Tracing GC为辐,以此解决卡顿等问题。

虽然我还没理清赵俊民大大说的五层架构,但是在我理解里,方舟的简易版架构差不多是上图这样的(原谅我对架构设计不熟悉)。

  • 首先是上面的部分,将libcore/OpenJDK、HarmonyOS Framework以及Android Framework用方舟编译器静态化编译为动态库.so,这个过程中,方舟Runtime里好像对于一些JNI方法进行了重新实现;这个.so里就是编译为机器码的Java类,不过其对象结构不同;需要注意的是,原本Framework依赖的底层动态库,静态化编译之后也还是会依赖的,不过不是直接体现在.so的依赖中,而是通过libandroidmpl-rt.so这个方舟运行时库进行加载,而且在libmaplecore-all.so中,可以找到如下的和native调用相关的符号:
  • 然后是图中下面的应用部分,同样通过方舟编译器编译为.so,和上述Framework编译没有区别;
  • 最后是执行部分:
    • 对于单纯的Java程序,提供了一个叫mplsh的程序用于启动、加载类、运行。这个也是目前开源提供的东西;
    • 而对于Android和HarmonyOS,则是通过魔改的zygote(叫mygote)进行加载、运行。

上述提到了HarmonyOS,因为我在最新的EMUI 11中看到了maple化的HarmonyOS Framework。在EMUI 11的/system/lib64下面可以找到的maple化的动态库有如下这些:

       /system $ find -iname *maple* ./lib64/libmapleandroid.hardware.light-V2.0-java.so ./lib64/libmapleandroid.hidl.base-V1.0-java.so ./lib64/libmapleandroid.hidl.manager-V1.0-java.so ./lib64/libmapleandroid.test.base.so ./lib64/libmapleandroid.test.mock.so ./lib64/libmapleandroid.test.runner.so ./lib64/libmapleapache-xml.so ./lib64/libmaplebouncycastle.so ./lib64/libmaplecaliper-api-target.so ./lib64/libmaplecom.android.location.provider.so ./lib64/libmaplecom.huawei.nb.sdk.so ./lib64/libmaplecom.huawei.nfc.so ./lib64/libmapleconscrypt.so ./lib64/libmaplecore-all.so ./lib64/libmapleethernet-service.so ./lib64/libmapleext.so ./lib64/libmaplefeaturelayer-widget.so ./lib64/libmapleframework.so ./lib64/libmaplehwEmui.so ./lib64/libmaplehwIAwareAL.so ./lib64/libmaplehwIms-common.so ./lib64/libmaplehwPartAirSharing.so ./lib64/libmaplehwPartBasicplatform.so ./lib64/libmaplehwPartBasicplatformServices.so ./lib64/libmaplehwPartCamera.so ./lib64/libmaplehwPartConnectivity.so ./lib64/libmaplehwPartDFR.so ./lib64/libmaplehwPartDFRServices.so ./lib64/libmaplehwPartDefaultDFR.so ./lib64/libmaplehwPartDefaultDFRServices.so ./lib64/libmaplehwPartDeviceVirtualization.so ./lib64/libmaplehwPartEyeProtectionOpt.so ./lib64/libmaplehwPartIaware.so ./lib64/libmaplehwPartIawareService.so ./lib64/libmaplehwPartMagicWindow.so ./lib64/libmaplehwPartMagicWindowServices.so ./lib64/libmaplehwPartMdm.so ./lib64/libmaplehwPartMdmServices.so ./lib64/libmaplehwPartMedia.so ./lib64/libmaplehwPartPickUpWakeScreenOpt.so ./lib64/libmaplehwPartPowerOffice.so ./lib64/libmaplehwPartPowerOfficeServices.so ./lib64/libmaplehwPartSecurity.so ./lib64/libmaplehwPartSecurityFaceId.so ./lib64/libmaplehwPartSecurityServices.so ./lib64/libmaplehwPartSingleHandServices.so ./lib64/libmaplehwPartTelephony.so ./lib64/libmaplehwPartTelephonyCust.so ./lib64/libmaplehwPartTelephonyFullnetworkOpt.so ./lib64/libmaplehwPartTelephonyOpt.so ./lib64/libmaplehwPartTelephonyTimezoneOpt.so ./lib64/libmaplehwPartTelephonyVSim.so ./lib64/libmaplehwPartVr.so ./lib64/libmaplehwPartVrService.so ./lib64/libmaplehwSelfCure.so ./lib64/libmaplehwServices.so ./lib64/libmaplehwSlaveWifi.so ./lib64/libmaplehwTelephony-common.so ./lib64/libmaplehwWifi-service.so ./lib64/libmaplehwWifiPro-service.so ./lib64/libmaplehw_mdm_framework.so ./lib64/libmaplehwcustEmui.so ./lib64/libmaplehwcustIms-common.so ./lib64/libmaplehwcustServices.so ./lib64/libmaplehwcustTelephony-common.so ./lib64/libmaplehwcustframework.so ./lib64/libmaplehwcustwifi-service.so ./lib64/libmaplehwframework.so ./lib64/libmaplehwperf.so ./lib64/libmapleims-common.so ./lib64/libmaplejacocoagent.so ./lib64/libmaplejsr305.so ./lib64/libmaplejunit.so ./lib64/libmapleokhttp.so ./lib64/libmapleorg.apache.http.legacy.so ./lib64/libmapleorg.ifaa.android.manager.so ./lib64/libmapleorg.simalliance.openmobileapi.so ./lib64/libmapleservicehost.so ./lib64/libmapleservices.so ./lib64/libmapletelephony-common.so ./lib64/libmapletelephony-separated.so ./lib64/libmapleupdatable-media.so ./lib64/libmaplevendor.huawei.hardware.tp-V1.0-java.so ./lib64/libmaplevoip-common.so ./lib64/libmaplewifi-service.so ./lib64/libmaplezframework.z.so     

与上面的图对应:

  • Android Framework: libmapleframework.so
  • HarmonyOS Framework: libmaplezframework.z.so
  • Maple Runtime: libmaplecore-all.so, libcommon_bridge.so, libandroidmpl-rt.so
  • 除此之外,还有例如apache-xml、com.huawei.nfc、android.hidl.base-V1.0-java等第三方Java库maple化后的动态库,也有hwEmui.so、wifi-service等系统服务的动态库。

安卓的System Services的maple化是很早以前就完成了的,单独拿这点来说,确实是个壮举。但是,这些东西都是closed world的,对于这些程序的代码,有很大的修改、定制空间,方舟编译器和这些代码可以互相成全。但是面对第三方应用时,情况就不同了,因为你没法限制这些应用使用的SDK版本、Java特性、热更新方案,也不能要求人家放弃某些动态特性,只能尽全力去兼容、兼容、兼容,然后就是性能和兼容性的trade-off。支持方舟编译器的安卓第三方应用有了,但是并没有大规模使用,估计就是这个原因。

而对于HarmonyOS,情况可以好很多,因为Android已经踩过很多坑了,历史兼容性问题也没有很多,可以尽可能发挥方舟的效用。以热更新为例,Android系统有特别多的方案,但在HarmonyOS,系统层面已经提供了热更新的方案(HarmonyOS 文档中心-HotFixClassLoader):

所以在安卓方向上的方舟不是重点也很正常

以上说的都是Java的编译,而对于JS的编译,从多方消息来看,华为内部正在做,这个可能才是重点。

非代码讨论到此为止。


内容太多了,以后有空我会写文章来具体分析,下面就大致讲一下大概的内容吧。

1. 对象结构

  • 编译出来的.so的正式名称叫MFile,Runtime有自己的ClassLoader来从MFile加载类信息;
  • 因为是Java的Runtime,目前其对象结构和Java有点类似,为了兼容JNI规范,这些结构都有重载的类型转换操作符转换为JNI里的结构:
    • MObject,对象,对应JNI的jobject;
    • MClass,类,MObject的子类,对应JNI的jclass;
    • MMethod,类方法,MObject的子类,以及对应的MethodMeta保存方法的元信息;
    • MField,属性,MObject的子类,以及对应的FieldMeta保存属性的元信息;
    • MArray,数组,MObject的子类,对应JNI的jarray;
    • MString,字符串,MObject的子类,对应JNI的jstring;
  • 有java.lang.invoke.MethodHandle相关的东西,所以可能已经支持lambda等特性了;
  • 反射信息从XXXMeta中获取;
  • 有一个还挺复杂的name mangler;
  • 每一个符号都有一个MUID,是基于MD5哈希生成的,这个用于虚表查找等地方;

2. JNI调用

  • 如上所说,兼容了JNI调用规范,将Runtime相关的结构转化为了JNI的结构,虽然本质上,JNI的那些结构就是一个指针;实现了JNI所有相关的方法;
  • JNI规定每一个JNIEnv是线程独有的,所以在方舟的Runtime的线程实现里,有一个获取JNIEnv的方法;
       // get a thread related  env virtual JNIEnv* GetJniEnv() const = 0;      
  • 依赖libnativehelper这个third party来查找动态库;
  • 在中端优化部分(src/mapleall/mpl2mpl/src/native_stub_func.cpp)中,会为native方法生成相关的stub方法;
  • native方法stub默认是一个weak符号,实现是抛出UnsatisfiedLinkError;JNI调用会被缓存;有一些libcore里的native方法在libcore-static-binding-jni和src/mrt/codetricks/arch/arm64实现,因为stub是weak的,所以链接上之后,这部分的JNI调用是直接调用;
                // Now native binding have three mode: default mode, dynamic-only mode, static binding list mode          // default mode, it will generate a weak function, which can link in compile time          // dynamic only mode, it won't generate any weak function, it can't link in compile time          // static binding list mode, it will generate a weak function only in list             
  • NativeCall分为Fast和Slow,实现在src/mrt/compiler-rt/src/arch/arm64/cc_native_method_stub_arm64.S;FastCall是直接通过x9寄存器保存函数地址一条br指令直接跳转;SlowCall也是使用x9寄存器,区别在于调用前会保存callee的现场,并且会进入safe region(不知道和JVM GC算法里的safe region是不是同一个东西);
  • SlowCall支持最多8个参数;

3. RC

  • 这部分有点复杂,还没细看;
  • 编译时对于创建对象的指令,生成RC相关的Intrinsics调用,然后代码生成时,lowering为MCC_XXX等RC相关的运行时实现;
  • Runtime里有相关的内存分配的allocator实现,借鉴了部分Rust的设计;
  • 有四种垃圾收集器实现:
    • 没有垃圾回收……
    • NaiveRC,NaiveRCCollector,单纯只用RC回收;
    • MarkSweep,MarkSweepCollector,基于标记-清除的Tracing GC;
    • NaiveRCMarkSweep,NaiveRCMarkSweepCollector,RC为主,Tracing GC为辅;
  • 垃圾回收类型可以在运行时动态设置;
       // Record gcIsGCOnly symbol address in echo RC compiled maple so // If not found, no action is need. // 1. At load time, check collector type and update // 2. At fork time/collector create time, update all according to new collector type     


user avatar   ikkiz-70 网友的相关建议: 
      
  1. 鸿蒙系统无论技术还是商业上都还没有完全展开,说“怎么样”为时尚早
  2. 如果只是作为手机系统的鸿蒙并不重要。MOV用不用鸿蒙不重要,重要的是PC,空调,冰箱,微波炉,汽车,高铁,无人机,手表,插线板,窗帘这些东西用不用鸿蒙
  3. 我不是硬件厂商,想用也用不了。手机版本短期内没啥可关注的,兴趣不大
  4. 前景广阔应该说目标是广阔的,能实现到啥程度目前还看不出来。目前的宣传肯定没有透露出全部想法,甚至一部分是误导性的信息。根据已知信息来看,布局非常宏大,但是当前拿出的东西很大程度上是基于现有系统拼凑的过渡产品。即使商业上能站稳脚跟,技术上至少需要一次类似于Windows2000的WindowNT/消费者Windows/WindowCE -> 统一到WindowNT的蜕变才能最终成型



  

相关话题

  华为发布 2020 年度报告,净利润 646 亿元人民币,同比增长 3.2%,还有哪些值得关注的点? 
  华为的鸿蒙系统你用起来怎么样? 
  如何看待华为 P50 Pro 开售就被抢购一空? 
  中国做编译器的人才大多数都在华为吗? 
  鸿蒙不仅可以用于手机,和鸿蒙唯独不能用于手机,是不是一个意思? 
  为什么华为喜欢做屏幕曲率大的手机,而其他品牌并不跟进? 
  如何看待荣耀20系列14天国内销售破百万台,再次刷新荣耀旗舰销售记录? 
  为什么说「华为芯片的断供」是近些年手机界“最大”的遗憾? 
  花3000至5000买华为MatePad pro的人是怎么想的? 
  如何评价「华为 P 系列学苹果,Mate 系列学三星,荣耀学小米,nova 学 ov」的说法? 

前一个讨论
如何评价比亚迪汉2020年11月销量达10105辆?
下一个讨论
三星取消附赠充电器耳机获证实,如何评价这一行为?其它手机厂商会跟随吗?





© 2024-11-08 - tinynew.org. All Rights Reserved.
© 2024-11-08 - tinynew.org. 保留所有权利