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の実装（まだまだ実験的）