Rest Term

Flash Runtimeの未来について

これからのFlash Runtimeについて紹介されています。
Flash Camp Brazil から - akihiro kamijo
スライドの情報量が少なすぎて少し無謀かもしれませんが勝手に妄想してみます。

とりあえず個人的に気になった項目だけ。

Faster Garbage Collection

* Incremental GC (インクリメンタルGC)
* Towards a generational collector without copy (コピーなし世代別GCへ)

まず、
インクリメンタルGCは今までやってなかったのでしょうか。
あれ?

やっていなかったという前提で、ではどこをインクリメンタル化するのか。
最近のFlashアプリケーションを見ていると、インスタンスを最初に作り溜めしておいて、
それらを最後まで使い回すというアプローチが今では一般化しているように見えます。
そういう作りだとマークフェイズに時間がかかってしまうので、
そこをインクリメンタルに実行すると効果が期待できそうですね。
どんなタイプのライトバリアを使うのかも気になります。

インクリメンタルGCだと停止時間が短くなる代わりにスループットが下がりますので、
これを考慮して世代別GCを採用という流れは自然ななりゆきだと思います。
ただ、世代別GCを採用する点については不安なところもあります。
前述のようにあらゆるオブジェクトを使い回す作り方をしていると、
それらが旧世代にぽんぽん移ってヒープがすぐにいっぱいになってしまいます。
世代別GCは、
「多くのオブジェクトは若くして死ぬ」
という一般的なプログラムの傾向に合わせて効率化したアルゴリズムなので、
今使っている最適化手法をそのまま使うとまずい事が多くなるはずです。
コストの高いMajor GC(Full GC)が頻発するのは避けたいところですが、
たぶん "GC hint API" というのはそういうのを上手くコントロールする為のものなんでしょう。
GCにヒープサイズや世代間移動のしきい値等をヒントとして与える感じかと。
Flashでもヒープパラメータをチューニングする時代がやってくるのかと思うとぞっとしますが、
その辺はJavaの世界だと何年も前に通った道ですので先人達に学べば大丈夫そうです。
そもそもオブジェクトプーリングみたいな手法がいまだに有効だという事実の方に驚き。
いずれにせよこの項目はスライド一枚の情報量なので詳細は全くわかりません。

あと少し話はそれてしまいますが、
FlashのGCについて調査・説明されているサイトは国内でもたくさん見つかります。
ただ、参照カウントの説明が不十分なところが多いんじゃないかなと思います。
Flashの参照カウントは実際は遅延参照カウント(DRC)だと僕は認識しているので、
その説明も含めて正しく書いた方がいいんじゃないかと。。どうでもいいか。

Concurrency

* Multiple ActionScript workers (Shared-nothing isolation model)

これはJavascriptにおけるWeb Workersと同様のものと考えてよさそうです。
ただ、コード例を見るとJavascriptのそれより多少煩雑に見えます。

function を詰めた Object を渡してますけど、スコープの扱いはどうなるんでしょう。
this はどう振る舞う? WorkerConneciton#call の第二引数はなに?
また、"Shared-nothing isolation model" というのも重要な性質で、
ワーカープロセス内からはワーカー作成元のDisplay Listにはアクセス不可になる感じでしょうか。
でもきっと、すぐに共有メモリ型のワーカーも提供されるんでしょうね。
だとすると事故大量発生な予感が、、このWorker機能については正直に言って不安も大きいです。
なぜならFlashのユーザー層はエンジニアだけではないのですから。「す、すれっど、、せーふ?」
(※ 発表されているのは今のところ shared-nothing な worker のみです。誤解なきよう。)

以下、その他について。

New numeric type: “float”

float/float4 型の導入については、昔 int/uint が追加された時に、
「それよりも1byteの型が欲しいよー」
みたいなコメントを特に海外のコミュニティでよく見かけたのを思い出します。
個人的にも1byteの型が欲しいなとずっと思っていました。あと多倍長整数。
そして案の定、Sneak Peek of Future of the Flash Runtime! - ByteArray.orgのコメント欄にも。
というかDineyさんのコメント過激すぎっていうか流れからして悪ノリw でもわりと好き。
全体を通してコメント欄がけっこう面白いので読むのオススメです。

また、Number型のメモリ管理について気になるところとしては、
(関連:Flashにおけるメモリ管理 « Rest Term)

つまり、値に応じてすぐに割り当てサイズが変わっています(getSize() の返却値を信じるなら)。
ByteArrayを使っていての感覚だと、きっと多階層でアロケータを持っているんだと思いますが、
どのレベルでどうやって最適なブロックを探しているんでしょうか。
Flashのメモリアロケータ周りの情報って見かけない気がしますね、。

Hardware Renderer, Stage3D

表示系の進化は素直にすごいと思いました。
Molehillも楽しそう。めんどくさそうですが、。
この辺りはライブラリの中で面倒見てくれるんでしょう、じゃないとツライ。。

 
思ったより長くなりましたが、
リリース時には興味なくしてる気もするので今の内にいろいろ妄想しておきました。
処理系がどんどん効率化されていくのは良いことだと思います。
ただ、現場の人達は今、例えばGCのStop-the-Worldでホントに困ってるのでしょうか。
僕は仕事で一度もFlashを使ったことがないので知らないのです、ごめんなさい。

あわせて読む:

 

Tags:

Comments: 3

Leave a reply »

 
  • k

    FlashPlayerのGCって参照カウントでしたっけ?
    マークアンドスイープだったような。
    単なるマークアンドスイープを改善するという認識でした。

    直接Number型を扱うインストラクションがAVM2には存在しないので、
    高速化のためにネイティブなfloat型でマッピングするということかなと思いました。

    Stop-the-Worldについては、現場では結構格闘していますよ。
    Arrayのインスタンスとかをループで作っているときに、よくフレームレートの低下を招くので、わかりやすいです。
    シングルスレッドであることを利用して、Arrayのインスタンスをstaticに持たせて使い回すとかで回避してます。

     
     
     
  • wellflat

    To: kさん
    貴重なコメントありがとうございます。

    > FlashPlayerのGCって参照カウントでしたっけ?
    > マークアンドスイープだったような。
    > 単なるマークアンドスイープを改善するという認識でした。
    参照カウントのバックアップとして(保守的な)マークアンドスイープするという認識でした。。
    以下のPDFの46pにGCのアルゴリズムについて書いてあるのですが、これは古い情報ということですか?
    http://www.onflex.org/ACDS/AS3TuningInsideAVM2JIT.pdf
    もし違ってたらごめんなさい><

    Number型の件は、なるほど勉強になります。ありがとうございます。

    あと、現場でもGCとはけっこう戦っているんですね。
    畑違いの僕から見ると、大変そうだけど面白そうにも見えます。
    Flashの現場の方々と交流する機会をもっと増やした方がいいのかなぁ。。

     
     
     
  • k

    すみません、僕の勘違いでした。
    メインストリームとして参照カウントGCにしつつも、
    よくある循環参照やデリファレンス漏れをマークアンドスイープで対処するって感じなんですね。

    自分は元々Java専門だったので、ごりっごりのActionScript3でも全然問題ないですが、旧来のFlasherではこの辺の話題はキツイと思います。

    結構有名なFlashやらActionScript3系のブロガーの人も、JavaとかC++出身が多いですよね。

     
     
     
  • Leave a Reply
     
    Your gravatar
    Your Name