これはこの質問の続きです。
私は、.NET DLL をリベースするかどうかをテストしている最中です。これらを NGEN 化すると、ターミナル サーバーのメモリ内により多くの共有コードが提供されるようになります。
しかし、私の計画には欠陥があるようで、アドレスの作業セットを把握するための作業方法を見つけることができないようです。
私ができると思ったのは以下のようなものです。
- すべてをビルドして NGEN にするだけ
- プログラムを開始し、すべての DLL がロードされていることを確認します
- LISTDLLS /R PROGRAMNAMEを使用して、実行中のインスタンスの現在使用中のアドレスのリストを取得します
- これらの DLL の新しいベースアドレスとして再マップされた DLL のアドレスを使用します。
- すべてを UN-NGEN し、1 からやり直す
ただし、一部の DLL をリベースすると、ロード順序が変更されるか、オペレーティング システムが他の DLL を再配置する方法が明らかに変わるため、これはシュレーディンガーの課題になりました。
たとえば、最初の実行後に、DLL A、B、および C がアドレス 1000、2000、および 3000 にある必要があるというリストがあるとします。DLL の一部でもある DLL D、E、および F については言及されていません同じシステム。おそらく、これらは現在のベースアドレスにロードされていると思われます。そうでなければ、LISTDLLS がそれについて教えてくれると思います。
そこで、A、B、C のアドレスを変更し、すべてを繰り返すと、DLL C、D、および E が再配置されました。A と B は OK になりました。E と F は移動しました。C はまだシャッフルされています。
私のマシンで何を理解しているかに関係なく、DLL が使用され、ターゲットのターミナル サーバーに挿入されると、この図が乱れる可能性があるため、この演習はやや無駄なものであることに気付きましたが、少なくともいくつかのことを確認できればDLL を所定のベース アドレスに配置すると、同じプログラムの複数のインスタンス間で共有されるコードの量が増加します。それを「思い出させる」必要がないように、ただ言っているだけです:)
すべての DLL の元のベース アドレスがデフォルトであったため、すべての DLL (おそらく最初にロードされたものを除く) が再配置され、ページ ファイルにマップされたため、0 を超える潜在的なゲインがあると思います。
何かアドバイス？