實驗三：測試 GLR parser 剖析時間

在此實驗，我們要測量的是在有使用或沒使用解決shift/reduce conflict 和 reduce/reduce conflict 技術的情況下，GLR parser 真正執行剖析時所花的時間，因 此這部份的時間計算並未包含解決shift/reduce conflict 演算法所花費的時間，如 Figure 4.3 所示。

Figure 4.4 衝突解決技術執行的位置

4.4.1 實驗設計

一個Java 原始程式轉成 bytecodes 再轉成 IR 時，其實 IR 是由一連串的樹所 組成的，每個樹的大小不一，而且多數的樹在交由我們GLR parser 依照即時編 譯器的指令文法去剖析時並不會讓剖析過程中有兩個以上的剖析堆疊的存在，如 此的IR tree 就不能被我們 GLR parser 所使用。因此，為了讓我們 GLR parser 在 處理某個樹所轉成的字串之後可以讓GSS 中有許多的剖析堆疊存在，我們先研 究了即時編譯器的指令文法，找出是哪些規則的什麼特色造成了shift/reduce conflict 或 reduce/reduce conflict 的情況，以方便我們設計 Java 程式。

在我們所使用的即時編譯器的指令文法中，共有 195 條規則，而在交由 Bison 當作輸入後，可發現共含有163 個 shift/reduce 衝突和 1587 個 reduce/reduce 衝突，

而很多衝突都是發生在一個稱作ICONST_32 的 terminal 身上，因此當我們 GLR parser 依照此模糊的指令文法去剖析一個由 IR tree 轉成的字串時，要能在剖析過 程中有多個剖析堆疊存在，則該IR tree 必須含有多個 ICONST_32 節點。而為了 要得到這樣的IR，我們在設計 Java 原始程式時，就必須含有許多的常數運算。

Table 4.3 列出了 JIT grammar 的資訊，其中包含了在 JIT grammar 中，多少比例 的shift/reduce conflict 和多少比例的 reduce/reduce conflict 能夠被處理，分別是 1.23%和 59.17%

Rules 195 Terminals 143 Non-terminals 19

FSM states 427

S/R conflicts 163

R/R conflicts 1587

Table 4.3 JIT grammar 的資訊

在設計好含有許多常數運算的Java 原始程式，然後取得其中我們所需的測 試檔後，接著就將指令文法JIT grammar 交由 NewBison 來處理，然後以產生出 來的GLR parser 來去剖析這些測試檔，以觀察 GLR parser 剖析完整個測試檔的 目標句子會花多少時間。

實驗的電腦是安裝Ubuntu 的作業系統，然後 CPU 是 Intel 3.4GHz，共 2GB 的記憶體。第一個測試的是沒有任何衝突解決技術的情況，然後因為在所有測試 檔的衝突中，reduce/reduce conflict 佔很大的部分，所以第二個要測試的是在只 有執行解決reduce/reduce conflict 技術的情況，第三個要測試的則是兩種衝突技 術都有使用的情況，第四個要測試的則是兩種解決conflict 技術都有使用的情況。

4.4.2 實驗結果

Table 4.4 顯示了所測試的結果，單位是毫秒(millisecond)，而每一次的測試都是 執行30 次再求平均數，括弧中的百分比則是顯示剖析時間減少的百分比。

Total Time Total Time with R/R Table 4.4 GLR parser 剖析時間(ms)

第一個測試檔由我們GLR parser 來處理，僅會遭遇到 1 次 shift/reduce conflict，因此在剖析過程中共會有兩個剖析堆疊的存在。而因為僅有 shift/reduce conflict 的存在，因此僅使用了解決 shift/reduce conflict 的技術，而未使用解決 reduce/reduce conflict 的技術。最終剖析所需的時間平均來說會減少 37.67%。第 二個測試檔雖然不會遭遇到任何的shift/reduce conflict，但會遭遇到 6 次

reduce/reduce conflict，所以在剖析過程中共會有 64 個剖析堆疊的存在。因為僅 有reduce/reduce conflict 的存在，因此僅使用了解決 reduce/reduce conflict 的技 術，而剖析所需的時間平均來說可以減少34.04%。第三個測試檔會遭遇到 1 次 shift/reduce conflict 和 3 次 reduce/reduce conflict，所以在剖析過程中共會有 16 個 剖析堆疊的存在。在使用了解決reduce/reduce conflict 的技術後，剖析時間會減 少24.26%，而使用解決 shift/reduce conflict 的技術則執行時間會減少 13..27%。

若兩個衝突解決的技術同時使用，則剖析時間會減少35.68%。第四個測試檔會 遭遇到2 次 reduce/reduce conflict，所以在剖析過程中共會有 4 個剖析堆疊的存 在，而在使用了解決reduce/reduce conflict 的技術後，執行時間會減少 35.76%。

第五個測試檔會遭遇到1 次 shift/reduce conflict 和 1 次 reduce/reduce conflict，所 以在剖析過程中共會有4 個剖析堆疊的存在。在使用了解決 reduce/reduce conflict 的技術後，執行時間會減少16%，而使用解決 shift/reduce conflict 的技術則執行 時間會減少21..53%。若兩個衝突解決的技術同時使用，則剖析時間會減少 37.97%。

從我們測試的結果可以看出，使用解決 shift/reduce conflict 和 reduce/reduce conflict 的技術確實可以減少我們 GLR parser 在剖析一個目標句子時所需要的時 間，但若能有更大的測試檔且含有更多的衝突，則可以做更精確的測試。雖然我 們所使用的指令文法儘管有163 個 shift/reduce conflict 和 1587 個 reduce/reduce conflict，但真正造成前者衝突的規則僅有幾條而已，造成後者衝突的規則則較 多，因此在找尋測試檔的過程中，比較不容易找到含有shift/reduce conflict 的目 標句子，至於所找到的測試檔最多也僅有63 個，主要是因為一個 Java 原始檔會 轉成一連串的中間表示樹，但大部份的樹都不會遭遇到任何的衝突，只有少數的 樹會遭遇到衝途，因此在未來希望能測試更多的Java 原始檔來找到更大的測試 檔。

這兩個衝突解決的技術雖然能確實減少剖析的時間，且儘管這五個測試檔中 的每個衝突都順利被解決，但就整體來看某些衝突仍然無法解決，因此這兩個技 術還有許多改進的空間。