Pure .NET Application

.NET

個人的には Pure .NET ということには必要以上に拘る必要は無いと思っていますが*1，かといって世間的な Managed/Unmanaged 論もちょっとステレオタイプすぎるかなと．
.NET，というより製品としての Microsoft CLR は，2 通りのスタンスを持っているところから見直してみましょう．

  1. .NET 環境の中で (または並列する形で)，従来のネイティブ環境とネイティブモジュールを実行する
  2. 従来のネイティブ環境の中でユーザーモードライブラリとして .NET 環境を実行し，.NET 言語で書かれたモジュールを実行・操作する

有名な P/Invoke や COM Interop はどちらかというと(1)の立場で登場することが多いように思います．「.NET でこういうことはできますか？」に対して「.NET 内部から Unmanaged コードを呼び出すことで実現可能です」というパターンですね．
一方(2)の製品や技術としては，ASP.NET や SQLCLR が有名です．Internet Explorer 内でアプレット的に実行させたり，VSTO のように .NET で書かれた UI やロジックで Office を 拡張するといった例もあります．
Pure .NET からスタートして結局無理で(1)も利用，というパターンは結構ありがちですが，(2)は元々最初からその方向性を狙っていないと見えてこないかもしれません．というより，大量にリソースをつぎ込んで「アプリケーション」を作るのメインなのか，大量にリソースをつぎ込んで「プラグイン」を整備するのがメインなのか，というあたりの方向性の違いなんでしょうかね．
ASP.NET や SQLCLR のアセンブリを局所的に見れば .NET な世界に見えるかもしれませんが，もっと引いた視点で見たシステム全体としてはもっといろいろな技術が混在しています．技術を統合していくという点では Microsoft は色々やっていますし，.NET が絡む分野でそこまでリソースをつぎ込めるのは体力的にも Microsoft ぐらいなのかもしれませんけど．
「.NET アプリケーション」という方向性についてはここ 5 年で問題点や改善すべき点が色々見えてきたかと思いますが，プラグイン的なものを .NET で大量生成するという方向についてはまだいくらか未開拓な部分が残っていそうです．
Windows でマクロ言語として使われることが多い VB Script / JScript にしても，そのルーツは COM や ActiveScript の世界なわけですが，今やある種独立した形で文化を形成しています．.NET をルーツとする Windows Workflow Foundation (WF) なども，うまく立ち回れば次期主役として独立できそうな可能性が見えるだけに，がんばってほしいところですね．WF を Windows Vista や Office 2007 に応用していく上で，「.NET を流行らせること」と「WF を流行らせること」を天秤にかけるとしたら，個人的には後者を優先して欲しいかなと思っています．ARTDINK あたりに敷居を下げた軽量デザイナとデバッガ作ってくれるなら予約入れて発売日に買いますよ．はい．

*1:Pure Java 信仰についても最近はどうなんでしょうね？ SWT 以降は結構変わってたりするのかなぁ？

CLR Hosting : 仮想メモリ編 (1)

.NET

地味に需要あるのかもしれないですなぁ．arton さんのところと MSDN Forums より．

Java と比べれば CLR Hosting API は How to 記事を書いて一発というわけにはいかないぐらい (MSDN に正確な仕様が書いてないぐらい) 暗部で，かつ苦労の割にうまく行くかどうか分からないという暗黒感たっぷりですが，ちょっとだけ時間がとれたので試してみました．例によって参考書はいつもの本ですが，今回は毛色を変えて MSDN Magazine の最新記事の引用文でも．


簡潔さを目指したために、多数の基本事項を省略しました。CLR のホスト機能の完全な概要に関しては、Steven Pratschner 氏の著書 Customizing the Microsoft .NET Framework Common Language Runtime (Microsoft Press、2005 年版) を参照してください。



今回は，CLR Hosting API を使用して，CLR が使用する Virtual Alloc/Virtual Free をフックするコードサンプルを作ってみました．ヒープサイズを制限するというところまでは行っていませんが，OutputDebugString で各 API 呼び出しのログを出力しています．
http://www.dwahan.net/nyaruru/hatena/CLRVM.zip

試してみて分かりましたが，SQL Server 2005 のように CLR の使用メモリ量を制限するのは，案外大変です．例えばアドレス 0x018f0000 から 0x038effff までを VirtualAlloc で確保したコミットした後，0x03000000 から 0x038effff までをデコミットできるかどうか？ できるとしてどうなるか？ といった部分をちまちまと詰めていく必要があります．なにげに結構面倒．
とりあえずある程度動いている版は main.cpp で g_ManagerMode に Mode_ReportEx を設定すると動きます．
これもデバッグメッセージに流すだけでまともな整形はやっていませんが，C# 側で延々オブジェクトの生成を行っていると次のように予約領域が徐々にコミットされていくのが見えてきます．

0x038a0000 - 0x0489ffff : 16777216 byte ( 10285056 byte committed)
    ↓
  オブジェクト確保
    ↓
  VirtualAlloc: MEM_COMMIT from 0x0426f000, 65536 byte 
    ↓
0x038a0000 - 0x0489ffff : 16777216 byte ( 10350592 byte committed)
    ↓
  オブジェクト確保
    ↓
  VirtualAlloc: MEM_COMMIT from 0x0427f000, 65536 byte 
    ↓
0x038a0000 - 0x0489ffff : 16777216 byte ( 10416128 byte committed)

後はまあ予約サイズまたはコミット済みサイズに基づいて，ある一定以上のリソースを要求する VirtualAlloc を失敗させてみるという感じでしょうかね．実装まだですけど．

Verifiable ByRef returns

.NET

.NET アプリケーションでのデッドロックの回避と検出の拡張技法 を読んでいて，相変わらずマニアックな記事を雑誌に載っけるなあと思いつつ，著者を見てみたら例の Atomicity & Asynchronous Exception Failures の Joe Duffy 氏ですか．

Joe Duffy は、Microsoft の共通言語ランタイム (CLR) チームの技術担当プログラム マネージャであり、マネージ コードの並行性プログラミング モデルに取り組んでいます。同氏は、www.bluebytesoftware.com/blog に定期的にブログを掲載しています。Professional .NET Framework 2.0 (Wrox、2006 年版) の著者でもあります。

この人のなら買ってみても良いかも．

Professional .NET Framework 2.0 (Programmer to Programmer)

Professional .NET Framework 2.0 (Programmer to Programmer)

image

閑話休題．Joe 氏の blog をつらつら眺め直していたら，こういう記事が．
Verifiable ByRef returns?
どこかで似たような話を見たなと思ったらこれですな．
id:ladybug:20060520#p1
id:ladybug:20060521#p6