# tunny-compiler

**Repository Path**: opencity-moco/tunny-compiler

## Basic Information

- **Project Name**: tunny-compiler
- **Description**: Tunny-compiler is a workspace designed to perform various performance optimizations and instruction set adaptations on the LLVM code base, including but not limited to VM, AI, and other areas.
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2023-12-04
- **Last Updated**: 2023-12-18

## Categories & Tags

**Categories**: Uncategorized

**Tags**: Llvm

## README

# tunny-compiler

## 介绍
Tunny-compiler is a workspace designed to perform various performance optimizations and instruction set adaptations on the LLVM code base, including but not limited to VM, AI, and other areas.

## 1.背景知识说明

### JIT vs OAT
#### 1、JIT   Just In Time
   运行时, 将热点”VM字节码“ 转 “机器码”. 
     “解释执行” 变 “机器直接执行”. 
* (纯解释执行 vs 直接执行, 理论执行效率差一个数量级)
* JIT会存盘profile文件, 但是一般不存盘机器码.

#### 2、AOT  Ahead Of Time
   在运行之前, 基于profile编译热点VM字节码, 或者全量VM字节码编译.
   编译结果存盘. 若有前序编译的机器码, 则直接运行.

* 相对JIT的优点是, 没有慢热过程, 启动即最优性能。
* 在移动设备上,提前在充电时AOT 比运行时JIT 有省电优势.

#### 缺点是, 一些运行时编译优化, 强于AOT的静态编译优化. 可能JIT比AOT性能还好.



## 2.已探索核心机会点(JNI, LLVM Multi-Stage Optimization)
### 背景: ART, JIT vs OAT

在Android ART的性能优化上, 以AOT为主，我们也应该主要在AOT上发力。

1) VM领域JIT性能>=AOT, 是基本always true的断言.  
    * (但是以'CPU算力换性能表现',在移动设备上不太合适)

2) ART比较特殊: JIT(充分预热后)与AOT性能接近.
      * ART的JIT因"优化管线短并且绝大部分公用", 导致JIT性能弱.

3) JIT需要预热才能达到最佳性能. 而安卓应用进程的生命周期大多不长.


## 3.寻找新的机会点：LLVM引入ART用于OAT编译，两个典型应用场景：




## 4.LLVM引入ART的价值及风险

### 1）项目价值

1、尽量, 尽早 将解释执行的ART VM Byte Code, 转成机器直接执行的Machine Code, 拿到性能收益;

2、引入LLVM到ART后, 编译器行业内的各种优化可以方便引入; 

3、为ART字节码的编译,引入语言穿透的编译优化能力。

   * 核心收益 是同样任务, 减少CPU指令数量.

### 2）风险与问题

1、引入LLVM做编译优化后, dex2oat的执行速度会比之前慢一个数量级. 
   * 所以我们需在云端做,避免在用户设备上做.


#### 
## 5.建议方向及节奏

1、短期聚焦: 完成LLVM引入ART.

2、让项目(LLVM引入ART), 更正规运作.

3、发散: 对编译领域, ART优化保持关注.



## 6.社区近期技术RoadMap
### 1、目标：参与开源社区讨论，设计并确定方案，当前方案（待与社区继续探讨优化）：
1、在VM的compiled code中为了支持GC或者异常处理，需要编译器提供如下信息： 在特定指令处，指定value存放的location(在哪个寄存器中或stack的什么offset)。在Hotspot中，这个信息是OopMap，在Android Runtime中这个信息是stackmap。

2、设计一种将stackmap信息与特定llvm-IR绑定的机制，可以考虑为每一条指令都提供一个类似于metadata的标记，让LLVM能在处理该指令时，纪录该指令处的活跃value所在location。LLVM中已有的“gc-live” operand bundle 就是类似的功能，不过它只能与statepoint指令结合。

3、同时，bundle本身不是指令， 需要保证它能与stackmap/statepoint一样充当优化屏障，阻止load等指令跨过它进行移动。这个方案通用性更好，并且由于没有改变原有指令，复用优化应该更容易。但是要确保优化不破坏stackmap信息的正确性，可能需要修改更多的位点。

### 2、调研技术方向：

1、内存分配上有多少native malloc是被类似于jni string传递这样不必要的动作触发，进一步为端云编译优化的实现提供优先级指导。

2、ART的逃逸优化分析。分析有多少object没有被线程共享，但是被分配到了heap上。

3、Odex代码效率调研：
   a 调研odex相对native是否引入了更多的frontend stall，以便确定能否用巨页、layout优化等方法获得性能提升
   b 调研odex相对native的ipc差异，以及差异形成的原因。

4、关键函数优化点分析。按照优先级逐个阅读较热的数百个系统关键函数，分析当前状态，确认优化点。