JIT編譯器推導求餘%上下界引發的一連串故事

kelthuzadx發表於2021-05-28
編譯

C1 RCE對%的處理

HotSpot VM的C1有個RCE（Range Check Elimination，範圍檢查消除）優化，所謂範圍檢查消除，就是為了正確的丟擲陣列越界異常，虛擬機器需要在陣列訪問的一些地方插入隱式的檢查，但是這些檢查會降低效能，比如在迴圈中每次迴圈都得檢查一次，所以HotSpot VM會想辦法在可能的地方消除這些檢查。我在看C1 RCE的時候發現目前它對求餘符號的支援較為薄弱，它只能處理形如下面的程式碼：

arr[x%arr.length] // 只有除數是x.length的時候，才能應用RCE優化

如果餘數是整數常量，它就不能工作了：

arr[x%3]
for(int i=0;i<10;i++){
  arr[x%10]
}

實際上，根據JLS的定義，我們知道如果除數為整數常量（且等於零，因為0作為除數會丟擲執行時異常），是可以推匯出結果的上下界的（也取決於被除數的正負），規則如下：

  • x % -y ==> [0, y - 1]
  • x % y ==> [0, y - 1]
  • -x % y ==> [-y + 1, 0]
  • -x % -y ==> [-y + 1, 0]

於是，我給JDK發了個patch，這個問題算是解決了。但是Nils提到，C2是否有相同的優化呢？後面Tobias幫忙確認了一下C2沒有，我再後來也進一步確認了，所以下一步是調研C2是否能應用同樣的優化。

調研為C2應用同樣的優化

本來以為是比較trivial的事情，為求餘節點的型別系統加點程式碼，推導一下上下界即可，實際上我也這麼做的，但是最後發現這樣沒有消除上下界。預設開啟-XX:+GenerateRangeChecks後，在陣列訪問過程中（Parse::array_addressing），C2仍然生成了範圍檢查。

除錯後發現推導上下界根本沒有執行，因為C2建立完求餘節點後，會執行一個IGVN的過程，即迭代的應用多種優化，其中就包括理想化，C2理想化是指應用很多區域性小優化的過程，在這個例子中就是特殊處理形如x%2^n,x%2^n-1和x%1的情況，如果除數是整數常量，它還會使用一個來自https://book.douban.com/subject/1784887/書裡面的演算法，即Division by Invariant Integers using Multiplication(by Granlund and Montgomery)，搜了一下知乎有類似的文章，想要了解細節可以讀讀https://zhuanlan.zhihu.com/p/151038723。知道了原因，於是我改了下程式碼，禁止了求餘節點的理想化，心想這總可以了吧。

還是不行

是的，還是不行。儘管我已經禁止了對求餘符號的理想化優化，但是範圍檢查還是生成了。。。我又繼續看程式碼，發現除了理想化的這個優化之外，C2在IR（中間表示）構造的過程中又 又 又 又 又對求餘運算做了個優化！如果除數是正整數常量，且是2^n，那麼C2會對它進行變形，IR如圖所示：

左邊的IR是 IR構造的時候C2做的優化後的效果，右邊是理想化優化後的效果。實際上它們做的事情本身是比較重複的，而且經過測試發現，理想化優化的演算法要好於IR構造過程中的優化：

一個簡單的micro benchmark：

public class ModPowerOf2 {
    @Benchmark
    public int testPositivePowerOf2() {
        int sum = 0;
        for (int i = 0; i < 1000; i++) {
            sum += i % 1;
            sum += i % 2;
            sum += i % 4;
            sum += i % 8;
            sum += i % 16;
            sum += i % 32;
            sum += i % 64;
            sum += i % 128;
            sum += i % 256;
            sum += i % 512;
            sum += i % 1024;
            sum += i % 2048;
            sum += i % 4096;
            sum += i % 8192;
            sum += i % 16384;
            sum += i % 32768;
            sum += i % 65536;
        }
        return sum;
    }

    @Benchmark
    public int testNegativePowerOf2() {
        int sum = 0;
        for (int i = 0; i < 1000; i++) {
            sum += i % -1;
            sum += i % -2;
            sum += i % -4;
            sum += i % -8;
            sum += i % -16;
            sum += i % -32;
            sum += i % -64;
            sum += i % -128;
            sum += i % -256;
            sum += i % -512;
            sum += i % -1024;
            sum += i % -2048;
            sum += i % -4096;
            sum += i % -8192;
            sum += i % -16384;
            sum += i % -32768;
            sum += i % -65536;
        }
        return sum;
    }
}

理想化：

Benchmark Mode Cnt Score Error Units
ModPowerOf2.testNegativePowerOf2 avgt 25 8746.608 ± 139.777 ns/op
ModPowerOf2.testPositivePowerOf2 avgt 25 8735.545 ± 86.145 ns/op

IR構造優化：

Benchmark Mode Cnt Score Error Units
ModPowerOf2.testNegativePowerOf2 avgt 25 8693.797 ± 7.844 ns/op
ModPowerOf2.testPositivePowerOf2 avgt 25 6618.652 ± 1.739 ns/op

所以我提了個patch，準備移除IR構造做的優化來解決這個問題。

結語

我認為為求餘節點推導上下界也是有意義的，如果以後有其他優化會變形為求餘運算，那麼它們可以應用這個推導，同時，為求餘做統一完善的型別推導這件事本身也是正確的，所以我又提了個patch。可以看到，最終我只消除了C1 arr[x%4]的範圍檢查，還是沒能消除C2 arr[x%4]的範圍檢查，是不是以後可以說C1有的地方做的比C2好了（狗頭hh。

相關文章