本文中涉及linux作業系統的底層一些知識，有興趣的可以繼續深挖

全域性檢視

上圖顯示了java原始檔從編譯到載入執行的全域性檢視，整個過程中最主要的步驟是

1. 編譯成過程，由編譯器對java原始檔進行編譯整理，生成java bytecodes
2. 類的載入和初始化，主要由classloader參與
3. 執行引擎 將位元組碼翻譯成機器碼，然後排程執行

這一部分的內容，解釋的非常詳細的某過於《深入理解jvm》和撒迦的JVM分享，這裡就不班門弄斧了。

那麼講上述這些內容的目的又何在呢，我們知道scala也是需要編譯執行的，那麼編譯的結果是什麼樣呢，要符合什麼標準？在哪裡執行。

答案比較明顯，scala原始檔也需要編譯成java bytecodes，和java的編譯結果必須符合同一份標準，生成的bytecode都是由jvm的執行引擎轉換成為機器碼之後排程執行。

也就是說盡管scala和java原始檔的編譯器不同，但它們生成的結果必須符合同一標準，否則jvm無法正確理解，執行也就無從談起。至於scala的編譯器是如何實現的，文中後續章節會涉及。

ELF可執行檔案的載入和執行

”CPU是很傻的，加電後，它就會一直不斷的讀取指令，執行指令，不能停的哦。“ 如果有了這個意識，看原始碼的時候你就會有無窮的疑惑，無數想不通的地方，這也能讓你不斷的進步。

再繼續講scala原始檔的編譯細節之前，我們還是來溫習一下基礎的內容，即一個EFL可執行檔案是如何載入到記憶體真正執行起來的。(本篇部落格的內容相對比較底層，很費腦子的，:)

Linux平臺上基本採用ELF作為可執行檔案的格式，java可執行檔案本身也是ELF格式的，使用file指令來作檢驗。

file /opt/java/bin/java

下面是輸出的結果，從結果中可以證實java也是ELF格式。

/opt/java/bin/java: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, BuildID[sha1]=bd74b7294ebbdd93e9ef3b729e5aab228a3f681b, stripped

ELF檔案的執行過程大致如下

1. fork建立一個程序
2. 呼叫execve來執行ELF
3. ELF的載入過程中會有動態載入和連結發生
4. 全域性變數的初始化，這一部分和glibc相關
5. 執行main函式

第一步：每一種二進位制格式，必須先註冊自己的處理控制代碼。

在檔案$KERNEL_HOME/fs/binfmt_elf.c中，init_elf_binfmt函式就實現了註冊任務

static int __init init_elf_binfmt(void)
{
  register_binfmt(&elf_format);
  return 0;
}

來看一看elf_format的定義是什麼

static struct linux_binfmt elf_format = {
  .module		= THIS_MODULE,
  .load_binary	= load_elf_binary,
  .load_shlib	= load_elf_library,
  .core_dump	= elf_core_dump,
  .min_coredump	= ELF_EXEC_PAGESIZE,
};

第二步：搜尋處理控制代碼，fs/exec.c

execve是一個系統呼叫，核心中對應的函式是do_execve，具體程式碼不再列出。

do_execve->do_execve_common->search_binary_hander

注意search_binary_handler會找到上一步中註冊的binary_handler即elf_format，找到了對應的handler之後，關鍵的一步就是load_binary了。動態連結過程呼叫的是load_shlib，這一部分的內容細細展開的話，夠寫幾本書了。

search_binary_handler的部分程式碼

retry:
  read_lock(&binfmt_lock);
  list_for_each_entry(fmt, &formats, lh) {
    if (!try_module_get(fmt->module))
      continue;
    read_unlock(&binfmt_lock);
    bprm->recursion_depth++;
    retval = fmt->load_binary(bprm);
    bprm->recursion_depth--;
    if (retval >= 0 || retval != -ENOEXEC ||
        bprm->mm == NULL || bprm->file == NULL) {
      put_binfmt(fmt);
      return retval;
    }
    read_lock(&binfmt_lock);
    put_binfmt(fmt);
  }
  read_unlock(&binfmt_lock);

 要想對這一部分內容有個比較清楚的瞭解，建議看一下臺灣黃敬群先生的《深入淺出Helloworld》和國內出版的《程式設計師的自我修養》。

 原始碼走讀其實只是個形式，重要的是能理清楚其執行流程，以到達指令級的理解為最佳。

Java類的載入和執行

在各位java達人面前，我就不顯示自己java水平有多爛了。只是將兩幅最基本的圖搬出來，展示一下java類的載入過程，以及classloader的層次關係。記住這些東東會為我們在後頭討論scala repl奠定良好基礎。

序列化和反序列化

Java體系中，另一個重要的基石就是類的序列化和反序列化。這裡要注意的就是當有繼承體系時，類的序列化和反序列化順序，以及類中有靜態成員變數的時候，如何處理序列化。諸如此類的文章，一搜一大把，我再多加解釋實在是畫蛇添足，列出來只是說明其重要性罷了。

spark-shell的執行路徑

前面進行了這麼多的鋪墊之後，我想可以進入正題了。即spark-shell的執行呼叫路徑到底怎樣。

首次使用Spark一般都是從執行spark-shell開始的,當在鍵盤上敲入spark-shell並回車時,後面究竟發生了哪些事情呢?

export SPARK_SUBMIT_OPTS
$FWDIR /bin/spark - submit spark -shell "[email protected]" --class org.apache.spark.repl.Main

可以看出spark-shell其實是對spark-submit的一層封裝,但事情到這還沒有結束,畢竟還沒有找到呼叫java的地方,繼續往下搜尋看看spark-submit指令碼的內容。

exec $SPARK_HOME /bin/spark -class org. apache .spark.
deploy . SparkSubmit "${ ORIG_ARGS [@]}"

離目標越來越近了,spark-class中會呼叫到java程式,與java相關部分的程式碼摘錄如下

# Find the java binary
if [ -n "${ JAVA_HOME }" ]; then
RUNNER ="${ JAVA_HOME }/ bin/java"
else
if [ `command -v java ` ]; then
RUNNER ="java"
else
echo " JAVA_HOME is not set" >&2
exit 1
fi
fi
exec " $RUNNER " -cp " $CLASSPATH " $JAVA_OPTS "[email protected]"

SparkSubmit當中定義了Main函式,在它的處理中會將spark repl執行起來,spark repl能夠接收使用者的輸入,通過編譯與執行,返回結果給使用者。這就是為什麼spark具有互動處理能力的原因所在。呼叫順序如下

1. SparkSubmit
2. repl.Main
3. SparkILoop

利用jvisualvm驗證

修改spark-class,使得JAVA_OPTS看起來如下圖所示

JMX_OPTS="-Dcom.sun.management.jmxremote.port=8300 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=127.0.0.1"
# Set JAVA_OPTS to be able to load native libraries and to set heap size
JAVA_OPTS="-XX:MaxPermSize=128m $OUR_JAVA_OPTS $JMX_OPTS" 
JAVA_OPTS="$JAVA_OPTS -Xms$OUR_JAVA_MEM -Xmx$OUR_JAVA_MEM"

修改完上述指令碼之後先啟動spark-shell,然後再啟動jvisualvm

bin/spark-shell
jvisualvm

 在Java VisualVM中選擇程序org.apache.spark.deploy.SparkSubmit，如果已經為jvisualvm安裝了外掛Threads Inspector，其介面將會與下圖很類似

 在右側選擇“執行緒”這一tab頁，選擇執行緒main,然後可以看到該執行緒的thread dump資訊

spark repl vs. scala repl

既然scala已經提供了repl, spark還是要自己去實現一個repl，你不覺著事有可疑麼？我谷歌了好長時間，終於找到了大神的討論帖子，不容易啊,原文摘錄如下。

Thanks for looping me in! Just FYI, I would also be okay if instead of making the wrapper code pluggable, the REPL just changed to one based on classes, as in Prashant's example, rather than singleton objects.

To give you background on this, the problem with the "object" wrappers is that initialization code goes into a static initializer that will have to run on all worker nodes, making the REPL unusable with distributed applications. As an example, consider this: // file.txt is a local file on just the master val data = scala.io.Source.fromFile("file.txt").mkString // now we use the derived string, "data", in a closure that runs on the cluster spark.textFile.map(line => doStuff(line, data)) The current Scala REPL creates an object Line1 whose static initializer sets data with the code above, then does import Line1.data in the closure, which will cause the static initializer to run *again* on the remote node and fail. This issue definitely affects Spark, but it could also affect other interesting projects that could be built on Scala's REPL, so it may be an interesting thing to consider supporting in the standard interpreter. Matei

上述內容估計第一次看了之後，除了一頭霧水還是一頭霧水。翻譯成為白話就是利用scala原生的repl，是使用object來封裝輸入的程式碼的，這有什麼不妥，“序列化和反序列化”的問題啊。反序列化的過程中，物件的建構函式會被再次呼叫，而這並不是我們所期望的。我們希望生成class而不是object，class相當於一個可變物件，而object是例項化的不可變的物件

最重要的一點：Scala Repl預設輸入的程式碼都是在本地執行，故使用objectbasedwraper是沒有問題的。但在spark環境下，輸入的內容有可能需要在遠端執行，這樣objectbasedwrapper的原始碼生成方式經序列化反序列化會有相應的副作用，導致出錯不可用。

scala repl執行過程

再囉嗦一次,scala是需要編譯執行的，而repl給我們的錯覺是scala是解釋執行的。那我們在repl中輸入的語句是如何被真正執行的呢？

簡要的步驟是這樣的

1. 在repl中輸入的每一行語句，都會被封裝為一個object， 這一工作主要由interpreter完成
2. 對該object進行編譯
3. 由classloader載入編譯後的java bytecode
4. 執行引擎負責真正執行載入入記憶體的bytecode

interpreter in scala repl

那麼怎麼證明我說的是對的呢？很簡單，做個實驗，利用下述語句了啟動scala repl

scala -Dscala.repl.debug=true

 如果我們輸入這樣一條語句 val c = 10，由interpreter生成的scala原始碼會如下所列

object $read extends scala.AnyRef {
  def () = {
    super.;
    ()
  };
  object $iw extends scala.AnyRef {
    def () = {
      super.;
      ()
    };
    object $iw extends scala.AnyRef {
      def () = {
        super.;
        ()
      };
      val c = 10
    }
  }
}

注意囉，是object哦，不是class。

interpreter in spark repl

那我們再看看spark repl生成的scala原始碼是什麼樣子的？

啟動spark-shell之前，修改一下spark-class，在JAVA_OPTS中加入如下內容

-Dscala.repl.debug=true

啟動spark-shell,輸入val b = 10,生成的scala原始碼如下所示

class $read extends AnyRef with Serializable {
    def (): $line10.$read = {
      $read.super.();
      ()
    };
    class $iwC extends AnyRef with Serializable {
      def (): $read.this.$iwC = {
        $iwC.super.();
        ()
      };
      class $iwC extends AnyRef with Serializable {
        def (): $iwC = {
          $iwC.super.();
          ()
        };
        import org.apache.spark.SparkContext._;
        class $iwC extends AnyRef with Serializable {
          def (): $iwC = {
            $iwC.super.();
            ()
          };
          class $iwC extends AnyRef with Serializable {
            def (): $iwC = {
              $iwC.super.();
              ()
            };
            private[this] val b: Int = 100;
              def b: Int = $iwC.this.b
          };
          private[this] val $iw: $iwC = new $iwC.this.$iwC();
            def $iw: $iwC = $iwC.this.$iw
        };
        private[this] val $iw: $iwC = new $iwC.this.$iwC();
          def $iw: $iwC = $iwC.this.$iw
      };
      private[this] val $iw: $iwC = new $iwC.this.$iwC();
        def $iw: $iwC = $iwC.this.$iw
    };
    private[this] val $iw: $read.this.$iwC = new $read.this.$iwC();
      def $iw: $read.this.$iwC = $read.this.$iw
  };
  object $read extends scala.AnyRef with Serializable {
    def (): $line10.$read.type = {
      $read.super.();
      ()
    };
    private[this] val INSTANCE: $line10.$read = new $read();
      def INSTANCE: $line10.$read = $read.this.INSTANCE;
     private def readResolve(): Object = $line10.this.$read
  }
}

注意到與scala repl中的差異了麼，此處是class而非object

IMain.scala vs. SparkIMain.scala

是什麼導致有上述的差異的呢？我們可以下載scala的原始碼，對是scala本身的原始碼在github上可以找到。interpreter中程式碼生成部分的處理邏輯主要是在IMain.scala，在spark中是SparkIMain.scala。

比較兩個檔案的異同。

gvimdiff IMain.scala SparkIMain.scala

gvimdiff是個好工具，兩個檔案的差異一目瞭然，emacs和vim總要有一樣玩的轉才行啊。來個螢幕截圖吧，比較炫吧。

注：spark開發團隊似乎給scala的開發小組提了一個case，在最新的scala中似乎已經支援classbasedwrapper，可以通過現應的選項來設定來選擇classbasedwraper和objectbasedwrapper.

下述程式碼見最新版scala，scala-2.12.x中的IMain.scala

  private lazy val ObjectSourceCode: Wrapper =
      if (settings.Yreplclassbased) new ClassBasedWrapper else new ObjectBasedWrapper

compiler

scala實現了自己的編譯器，處理邏輯的程式碼實現見scala原始碼中的src/compiler目錄下的原始檔。有關其處理步驟不再贅述，請參考ref3,ref4中的描述。

有一點想要作個小小提醒的時，當你看到SparkIMain.scala中有new Run的語句卻不知道這個Run在哪的時候，兄弟跟你講在scala中的Global.scala裡可以找到