（もう少し情報があるかもしれないので）W32TeXですがやはり落ちます．場所も同様のようです．
fontloader 周りのようです．次の内容のファイルを texlua で処理させると落ちました．
確認しました．なるほど，最近の luaotfload はもう本体の fontloader を使っていないのでしょうが，luatexja は使うから落ちるわけですか．
最近の luaotfload はもう本体の fontloader を使っていないのでしょうが，luatexja は使うから落ちるわけですか．
そのようですね．
本当は luaotfload の使っている（Lua で書かれた）fontloader が使えればよいのですが， そちらの仕様がよくわからない（かつどんどんフォーマットが変わっていっている？）のが厄介です． その点，LuaTeX 本体の fontloader だと，Reference Manual にきちんとデータ構造が書かれているので， 現状の LuaTeX-ja では本体の fontloader を（いくつかのフォントの情報を得るため）使っている，というわけです．
一応 SEGV なので LuaTeX ML に投げてみました．
LuaTeX rev. 6310 で動くようになりました． diff を見た感じ，luatex 組み込みの fontforge (fontloader) がデフォルトでは float (32 bit) で処理している部分があるのですが，Source Han Serif を扱うには float では不足で，double (64 bit) を使うように指定してやると動くようになるということのようです．
これで Linux 環境の LuaTeX でも
のように気軽に太明朝が使えるようになりました（ただし，フォントキャッシュの読み込みにちょっと時間がかかります）．
こちらでも r6310 で動くことを確認しました．
# LuajitTeX で 7 ウェイトを同時に出力させようとしたら，キャッシュ生成の時点で Lua 側のメモリ制限にひっかかっていますね……．
# LuajitTeX で 7 ウェイトを同時に出力させようとしたら，キャッシュ生成の時点で Lua 側のメモリ制限にひっかかっていますね……．
情報ありがとうございます．試してみると，LuajitTeX より LuaTeX の方がキャッシュの読み込みが速いような気もします．
LuaJIT のメモリ制限については， http://stackoverflow.com/questions/35155444/why-is-luajits-memory-limited-to-1-2-gb-on-64-bit-platforms に説明がありました．
Fork\documentclass{ltjarticle}
\begin{document}
いろはにほへと
ちりぬるを
わかよたれそ
つねならむ
うゐのおくやま
けふこえて
あさきゆめみし
ゑひもせす
\end{document}
None への返信
すみません途中で送信しました．
上の文書を作業ディレクトリに luatexja.cfg
\def\ltj@stdmcfont{NotoSerifCJKjp-Regular}
\def\ltj@stdgtfont{NotoSansCJKjp-Regular}
を置いてコンパイルすると問題なく NotoSerif が使えるのですが，kmaeda さんが仰る通りキャッシュ読み込みに時間がかかります．
私の環境 (Debian 8.7; TeX Live 2017) ではコンパイルにかかる時間は
| LuaLaTeX (1.0.4) | LuaJITLaTeX (1.0.4) | |
| IPAex (default) | 0.5 s | 0.8 s |
| NotoSerif | 6.1 s | 2.1 s |
どちらも $HOME/.texlive2017 のキャッシュを読み込んでいるように見えるのですが，ここまで差が出るのは何故なのでしょうか．
また，高速化できる方法があればお教えいただけると幸いです．
コンパイルにかかる時間
きちんと調べてはいませんが，フォントの規模自体が違うことが大きいと思います．
例えば luaotfload によるキャッシュを調べると，私の環境では
$ ls ipaex*.lua sourcehan*.lua -l -rw-r--r-- 1 h7k h7k 2178910 5月 1 09:46 ipaexg.lua -rw-r--r-- 1 h7k h7k 2185850 5月 1 09:46 ipaexm.lua -rw-r--r-- 1 h7k h7k 10328828 5月 1 10:52 sourcehansans-regular-1.lua -rw-r--r-- 1 h7k h7k 10557099 5月 1 10:52 sourcehanserif-regular-1.luaとなっており， SourceHanSerif/Sans のキャッシュの容量は IPAex のそれの 5 倍ほどです．
また，luaotfload 以外にも，LuaTeX-ja は独自で縦書きに関するキャッシュを作りますが，こちらは
$ ls *ipaex*.lua *sourcehan*.lua -l -rw-r--r-- 1 h7k h7k 266834 5月 1 09:46 extra_ipaexg.lua -rw-r--r-- 1 h7k h7k 266856 5月 1 09:46 extra_ipaexm.lua -rw-r--r-- 1 h7k h7k 2346545 5月 1 10:51 extra_sourcehansans-regular.lua -rw-r--r-- 1 h7k h7k 2341148 5月 1 10:38 extra_sourcehanserif-regular.luaと桁レベルで違っています．
なお，フォントのキャッシュは自動的に .luc (LuaTeX), .lub (LuaJITTeX) としてコンパイルされ，次回以降の読み込みが早くなるようになっています．
ただ otc 版の SourceHanSerif/Sans などの「大きな」フォントを LuaJIT(La)TeX で使う場合，LuaJIT のメモリ制限に引っかかってコンパイルがうまくいかないことがあります（結果の .lub ファイルが0バイトになります）． 例えば，これを書いているマシン (Gentoo amd64, Core i5-3427U) では
luajitlatex IPAex 1.33 lualatex IPAex 1.46 luajitlatex SourceHanSerif/Sans 24.55 lualatex SourceHanSerif/Sans 2.96と，LuaJIT(La)TeX ではかえって遅くなってしまっています．
h7k への返信
お返事ありがとうございます．
コンパイルにかかる時間
きちんと調べてはいませんが，フォントの規模自体が違うことが大きいと思います． 例えば luaotfload によるキャッシュを調べると，私の環境では
(中略)
と桁レベルで違っています．
私の環境でも同程度のファイルサイズでした． 結局メモリにうまく乗るかどうかという話でしたね，お騒がせしました．
完了とします．
LuaTeX 本体と LuaTeX-ja のどちらが原因かわかりませんが，とりあえず．話題の源ノ明朝をダウンロードして試してみたのですが，
で，私の環境だと... (/home/kmaeda/texmf/tex/luatex/luatexja/src/patches/lltjp-fontspec-immediate.st y LaTeX Warning: You have requested package `fontspec', but the package provides `lltjp-fontspec-immediate'. ) (./test.aux) (/home/kmaeda/texmf/tex/luatex/luatexja/src/patches/lltjp-fontspec.sty) ABD: EverySelectfont initializing macros(load luc: /home/kmaeda/.texlive2016/te xmf-var/luatex-cache/generic/fonts/otl/sourcehanserif-regular.luc)zsh: segmentation fault lualatex testとなります．luajitlatex にするともう少し読み進むのですが，やはり落ちます．luatexja を読み込まない場合は落ちません．LuaTeX のバージョンは 1.0.5 (rev. 6306) で試しています．TL2016 のバイナリでも同様です．まず，同様の現象が他の環境でも再現するでしょうか？
（上の LaTeX Warning も少し気になっていますが，これはまた別の話．）