Slide 1

Slide 1 text

https://pawoo.net/@atsushieno Licensed under cc-by 4.0

Slide 2

Slide 2 text

この チョークトーク セッション Speaker Visual Studio for Mac (2017年5月Xamarinリリースのキモ) Xamarinを支えるコード生成エンジン その他の未来的トピック 難易度高いって聞いたけど

Slide 3

Slide 3 text

この チョークトーク セッション前にお願いしたいこと スライドは公開しています https://speakerdeck.com/atsushieno/ から探してください。 そういうわけで写真撮影は不要です。 SNSに流したいでしょうから撮影はご自由に(他参加者には配慮してください)。 評価は適切にしてください

Slide 4

Slide 4 text

past, present and future

Slide 5

Slide 5 text

Visual Studio for Mac

Slide 6

Slide 6 text

Build 2017で正式リリース 実態 Xamarin Studioです。 新機能 (一応触れておきます) Azureサポートの統合 C# 7サポート .NET Coreサポート Unity for VSMac ASP.NETプロジェクトのサポート Multiplatformライブラリ (Nugetizer 3000) Xamarin.IoT Android designer refresh IDEに統合されたAndroid SDK Manager

Slide 7

Slide 7 text

Mono 5.0: more .NET unification コンパイラ Roslynベースのcscがついに登場、C# 7をサポート(mcsはC# 6まで) ※MonoDevelopはv6.0からRoslynだった ランタイム デバッグシンボルファイルがmdbからPortable PDBに切り替わった クラスライブラリ 一部referencesourceからcorefxへの切り替えなど

Slide 8

Slide 8 text

MSBuildに切り替わった どういう意味…? これまでのはMono版の実装 xbuild github/Microsoft/msbuildの統合 Windowsべったりの初期コードをXamarinが合併前から協力して修正 現在は.NET Coreサポートでも利用 Cscタスクはcsc(.exe)を呼び出す 新しいエンジンだと不安が… プロジェクトによる ※WindowsではもともとMSBuildしかなかった プロジェクト オプションで切り替え可能(だけど新msbuildに依存しているかも)

Slide 9

Slide 9 text

予測されるトラブル(!) MDBが無い 下位VS/XS互換性が無いNuGetパッケージがビルドされる ※Xamarin.Forms 2.4 mdbの存在を前提にしたツールがクラッシュする(!?) C#コンパイルが遅くなった …10倍くらい。mcsはかなり最適化されていた(例: @csc.rspが無い) ビルドタスクがエラーを出すようになった 実装が根本的に変わったので互換性問題が生じるカスタムタスクが多々あるかも preview中にハマった例: Xamarin.FormsのXamlC / XamlG

Slide 10

Slide 10 text

Multiplatform Library bait & switch方式のNuGetパッケージを自動生成 Bait & switch方式…についてはここでは説明しません baitを自動生成するApiIntersect + 自動化ビルドタスク NuGetパッケージング プロジェクト (.nuproj) デフォルトで含まれる NuGet.Build.Packaging nugetパッケージがキモ 参照プロジェクトを追加するとビルド結果のnupkgに含まれるようになる nuprojのプロパティでPCLプロファイルを選択するとbaitも生成されて含まれる

Slide 11

Slide 11 text

Azure統合 クローズドソースなので多くは語れませんが… MonoDevelop.ConnectedServices ここはオープンソース Azure実装 ある程度はNuGetパッケージでWindows VSと共通化しているが、独自実装が多い NuGetパッケージもプロプラエタリでLinuxサポートも無い…今後の課題 NuGetパッケージ中心なのでAPIを知っていれば独自拡張も作りやすい?

Slide 12

Slide 12 text

Xamarinを支える コード生成エンジン

Slide 13

Slide 13 text

コード生成エンジンの位置付け Monoランタイムの構成 Mscorlib(ライブラリ) - C#で実装されている mono(ランタイム) - Cで実装されている Monoランタイムの仕事 ネイティブのI/Oやスレッド処理など(主にmono/io-layer) メモリ管理(主にmono/sgen) MSIL(mscorlibを含む)をロードして解釈する部分(主にmono/metadata) MSILをコンパイルして対象CPUに合わせたコードを生成する(主にmono/mini)

Slide 14

Slide 14 text

C#のコードがコンピュータ上で動くまで C#コンパイラがC#ソースをMSIL(.exeや.dll)に変換する .NETの仮想マシンがMSILをそのコンピュータ上のCPU命令として実行する

Slide 15

Slide 15 text

Interpreter vs. JIT 仮想マシンコードMSILを実行するやり方 バイトコード命令をフェッチして、解釈して実行する(インタープリタ) CPU命令に変換して、それをそのまま実行する(コードジェネレータ) JIT(実行時変換) vs. AOT(事前変換) 200x: 「Monoランタイム = JIT」の時代 2002年ころまでのmonoはインタープリタ (mint)、それ以降は基本的にJIT (mini) 200x年代後半まではJITの最適化だけやっていられた平和な(?)時代

Slide 16

Slide 16 text

「安全な」コード生成が必要な環境の登場 Google NaCl / PNaCl ブラウザ上でネイティブコードを実行 = 危険 一部のコード生成を強制的に安全化(一部x86ジャンプ命令の書き換え etc.) iPhone SDK 一部の許されたアプリにしかコード生成が実行できない環境 AOTで対応 iPhone以前から組み込み環境向けに実現していた 組み込みMonoについて: Essential Xamarin -Yin/陰-

Slide 17

Slide 17 text

不完全AOTと完全AOT 不完全? AOT不可能/困難な部分はJITで実行していた(不完全AOT) しかしそれでは完全AOTが「必須の」環境でコードが実行できない (※hybrid AOT - 不完全AOTのこと) どんな場面でAOTが困難/不可能? 非コンパイル済みコード(動的なコード)の実行 ※System.Reflection.Emit ジェネリック型を使うメソッドがいろいろ鬼門

Slide 18

Slide 18 text

.NET Generics: 静的コード生成の鬼門 ジェネリックメソッドは何が特殊なのか ジェネリック型の「インスタンス化」(ネイティブコード生成時)の問題 ジェネリックな値型が引数になると、確保するスタック領域のサイズが変わる Field Size Offset X 4 0 Y 2 4 Z 4 6 struct Foo { public int X; public T Y; public int Z; } Field Size Offset X 4 0 Y 8 4 Z 4 12

Slide 19

Slide 19 text

Generic Code Sharing ジェネリックコード共有 具体型ごとに異なるネイティブコードを生成していたらパフォーマンスが悪い そのため、JITはネイティブコードを共通化できる部分はコードを共通化している Monoでは2005年前後にがんばって実装していた = 共通化できない部分は、実行時のジェネリック引数型から動的に生成

Slide 20

Slide 20 text

Generic Code Sharing Xamarin.iOSでの対応 一定のサイズまではどんな構造体にも対応できるよう、固定サイズでスタックを確保 Field Size Offset X 4 0 Y 2 4 Z 4 X+4 Field Size Offset X 4 0 Y 8 4 Z 4 X+4 struct Foo { public int X; public T Y; public int Z; }

Slide 21

Slide 21 text

さまざまなGenerics なぜ.NETでのみ問題? .NET: reified genericsの世界(MSIL中でも, IList`1) Java: erased genericsの世界(制約型あるいはjava.lang.Objectに置き換え) C++: コンパイル時に型ごとに異なるネイティブコードが生成される cf. RTTI (Javaも将来的にreified genericsになりそう) ※ジェネリクスについては6/24の「generics勉強会」で!

Slide 22

Slide 22 text

ネイティブコード生成のオプション コード生成には多様な特徴・選択肢がある(べき) 例: メモリ容量の厳しい環境 例: 時間をかけて実行効率の高いコード生成が行える 例: X86のことしか考えていない(例えばendianness) →いくつかはmonoのビルド オプションや実行時オプションに

Slide 23

Slide 23 text

LLVMの登場 LLVMとは何か? コンパイラ用の抽象的なバイトコードを提供するコンパイラ インフラストラクチャ LLVM IR(intermediate representation) 任意の言語コンパイラのフロントエンド: C、C++、Objective-C、swift、... 任意のコード生成のバックエンド: x86、x86_64、ARM、MIPS、… (from "AOSA" - LLVM

Slide 24

Slide 24 text

mono-llvm LLVMフロントエンドとしてのMSIL処理系 LLVMフロントエンドがプログラミング言語である必要はない mono-llvmの意義 LLVMがサポートするさまざまなバックエンドを利用可能 LLVMが実装しているネイティブコード生成の最適化を利用可能 ランタイムサイズが肥大化する ちなみに.NET Coreの場合 Ryujit vs. LLILC (alive?)

Slide 25

Slide 25 text

Apple WatchOSとtvOSのサポート WatchOSとtvOSは何が特別なのか iOSと異なり「完全な」LLVM IR(bitcode)が要求される mono-llvmは全てのMSILコードを全てbitcodeに変換していたわけではない がんばって対応した

Slide 26

Slide 26 text

WebAssembly ブラウザで実行するネイティブコード 発端はasm.js ネイティブコードを実行するための仕様という意味ではPNaCLの改善版といえる WebAssemblyの命令セット (MIR) 処理系中立で安定した命令集合 LLVM bitcodeやPNaCLとは異なる目的(あちらは最適化) Safariや Edgeでも 実装している Think Web (TechBooster)

Slide 27

Slide 27 text

Mono for WebAssembly? ブラウザで実行するMSILコード 過去の取り組み MSILからJSを生成(Script#、Bridge.NET、JSIL) ブラウザ プラグイン(Silverlight、Unity Web Player、PNaCl) 現代的な取り組みならWebAssemblyサポートではないか ilwasm ... で出来るレベルではなさそう Web APIへアクセスできるかという問題? => WebSharp WebAssembly post-MVP: ネイティブGC統合や動的ライブラリなど、課題はある

Slide 28

Slide 28 text

Mono for WebAssembly? dnfdn

Slide 29

Slide 29 text

まとめ Mono/Xamarinは未来の実行環境に対応できる? JIT: 仮想マシン命令からCPU命令を生成 AOT: 動的コード生成の禁止に対応 iOS LLVM backend: mono固有のコード生成エンジン以外に対応 bitcode: 安全な実行コードを意識した仮想マシン命令に対応 WatchOS WebAssemblyの時代にも生き残れる? Xamarinが将来求められる動作環境は?

Slide 30

Slide 30 text

その他の未来的トピック

Slide 31

Slide 31 text

Xamarin Live Player (XLP) preview 由来はContinuous Coding http://praeclarum.org/post/132881570743/live-coding-with-xamarin-ios さらに遡るとInstant programming AppleのPlayground 詳しくは http://qiita.com/atsushieno/items/141f790a9bbaa93b62c1 Inspector 技術的にはInspectorを利用 変更点 C#はRoslynベース、実機で実行、デバッグ機能追加、主な対象がFormsのみに

Slide 32

Slide 32 text

xaml-standard XAMLを使ったUIマークアップの共通化? ”XAML Standard proposals are filed as issues serving as living documents describing the current thinking about a XAML feature/API." まだ何も言っていないに等しい…? 何が共通化できるの? 未定(RFC) どうやって実現するの? 未定 「というか、whatやhowよりwhyでしょ。何でそんなことしたいの?」

Slide 33

Slide 33 text

Xamarin.Forms v3 Forms embedding Formsのページをプラットフォーム ネイティブのコントロールとして作成可能に これでFormsのページナビゲーションモデルからおさらばできる プラットフォームの追加 Xamarin.Mac、GTK#、WPF その他 CSS方式のスタイリング、FlexLayoutもどき、初期化時のみのバインディング、 fast rendererへの切り替え

Slide 34

Slide 34 text

Embeddinator-4000 What's this? ネイティブ(Java/Kotlin/Obj-C/Swift)アプリケーション上にXamarinを組み込む 基本的にネイティブを使いつつ部分的に.NETのコードを使えるようにする Embedded mono + strongly typed .NET API 自分の.NET APIからC API / Java API (まだ無い) / Obj-C APIを自動生成 ツールチェイン - CppSharpを活用 C++ Interopの実装(まだまだ実験的)