問題タブ [jit]

コンパイルされた JIT であることを確認したい関数があります (つまり、呼び出される直前)。これを保証する属性またはアセンブリ設定はありますか? そうでない場合、関数がコンパイルされた JIT であることをどのように保証できますか?

ありがとう！

編集：

参照されているアセンブリが見つからないためにアプリケーションがクラッシュするのを防ぐために、これを行いたいと考えています。関数が JIT でコンパイルされている場合、不足しているアセンブリを参照する関数呼び出しを try...catch ブロックでラップし、状況を適切に処理できます。

クラス全体 (またはアプリケーション全体) が Jitted になる可能性があることを理解しています。これにより、おそらくキャッチできなかったエラーが発生します。

コンパイラ クラスの C# コンパイラの作業を続けています。現時点では、教科書のコンパイラの最適化に関する章をほぼ読み終えています。

ほとんどの場合、私の教科書は作成時に Just-In-Time コンパイルを念頭に置いていませんでした。C# コンパイラが実行する JIT プロセス中の静的な pre-jit 最適化の種類と比較して興味があります。 ?

CLR に対してコンパイルすることについて人々と話すと、「ほとんどの最適化は JIT によって行われる」などの言葉をよく耳にします。

ループのアンローリング、定数の折りたたみ/伝播、命令のインターウィービングなどは、C# のコンパイラによって pre-Jit で行われますか、それともジッターによって処理されますか? それらがジッターによって処理されない場合、ジャストインタイム コンパイラに固有のジッターはどのような最適化を行うのでしょうか?

間にパフォーマンスの違いがあるかどうか疑問に思っています

1. 文字列 s = someObject.toString(); System.out.println(s);

   と

2. System.out.println(someObject.toString());

生成されたバイトコードを見ると、違いがあるようです。JVM は実行時にこのバイトコードを最適化して、両方のソリューションで同じパフォーマンスを提供できますか?

この単純なケースでは、もちろん解決策 2 の方が適切に思えますが、読みやすさのために解決策 1 を好むこともあり、重要なコード セクションでパフォーマンスが「低下」しないようにしたいだけです。

C++ COM オブジェクトを使用する C# アプリケーションがあり、どちらも 32 ビット マシン上に構築されています。今、私はそれらを64ビットマシンで実行する必要があります。COM オブジェクトを登録しました。computer\hkey_classes_root\wow6432node\clsid{xxx} の下のレジスタに、対応するエントリが作成されました。しかし、アプリケーションを実行しようとすると、 |「CLSID {xxx} のコンポーネントの COM クラス ファクトリを取得できませんでした。次のエラーが原因で失敗しました: 80040154.」と表示されます。私が理解しているように、エラーコードはクラスが登録されていないことを意味します。助けてください！！！ありがとう

私は現在、Android プラットフォームに関する論文を書いています。いくつかの調査の結果、Dalvik には改善の余地があることが明らかになりました。この目標を達成するために、開発者の時間をどのように使うのが最善だと思いますか?

JIT コンパイルは大きなもののように思えますが、これはリソースの少ないマシンではあまり役に立たないと聞いたことがあります。これを裏付けるリソースまたはデータを持っている人はいますか?

考慮すべき他のオプションはありますか？VM をバイパスするための堅牢なネイティブ開発キットの開発は別として。

興味のある方は、 Dalvik VMに関する講義を録画してオンラインに公開しています。

この質問は主観的に見えるので、どんな考えも歓迎します。私が受け入れる答えには、提案された変更の正当性がなければならないことを明確にします。Sun JVM が導入されたときの改善など、それを裏付けるデータがあれば、非常にプラスになります。

Process.Start() を介してアンマネージド C++ アプリケーションを呼び出す C# アプリがあります。

一部のマシンでは、この C++ アプリが異常終了すると、Just-In-Time エラー ダイアログが表示されたままになります。

C++アプリにエラーが発生したことをC#から検出して再起動する方法はありますか

(ソースがないため、C++ アプリを変更できません)

JVM / CLRはJITコンパイル済みネイティブコードをどのように実行しますか？コードインジェクションによるものですか、それとも実行可能メモリへのコードのコピーによるものですか？動的なコード実行を可能にするシステムコールとは何ですか？

私は入れ子になった try/catch ステートメントについて考えてきましたが、JIT がコンパイルされた IL の最適化または単純化を実行できる条件があるとすれば、それについて考え始めました。

説明のために、例外ハンドラの次の機能的に同等の表現を考えてみましょう。

ネストされた try ステートメントのスタック フレーム内に追加の変数参照や関数呼び出しがないと仮定すると、JIT は、スタック フレームが線形の例に折りたたまれている可能性があると結論付けることができますか?

では、次の例はどうでしょうか。

JIT がデリゲート呼び出しをインライン化する方法はないと思うので、この例を前の例に還元することはできません。ただし、 をfoo()スローExceptionCした場合、線形の例と比較して、このソリューションのパフォーマンスは低下しますか? フレームに含まれる余分なデータは最小限ですが、デリゲートの呼び出しからスタック フレームを破棄するには余分なコストがかかると思います。

時間の経過とともに、Sun の JVM と JIT はかなりスマートになりました。マイクロ最適化が必要であると以前はよく知られていたことは、あなたに代わって処理されるため、もはや必要ありません。

たとえば、以前は、可能なすべてのクラスを final としてマークする必要があったため、JVM はできるだけ多くのコードをインライン化しました。ただし、現在、JIT は、実行時にロードされるクラスに基づいてクラスが final であるかどうかを認識しており、クラスをロードして元のクラスを final 不可にする場合、メソッドのインライン化を解除し、そのマークを解除します。最後の。

JVM または JIT は、他にどのようなスマートなマイクロ最適化を行いますか?

編集: これをコミュニティ wiki にしました。時間をかけて集めていきたいと思います。

Linkers and Loadersという本の中で、実行可能ファイルに別のコード セクションがある理由の 1 つは、コード セクションを読み取り専用ページに保持できるため、パフォーマンスが向上すると述べられています。これは最新のOSにも当てはまりますか？ジャストイン タイム コンパイラがオンザフライでコードを生成していることを考えると、書き込み可能なページが必要だと思います。これは、JIT で生成されたコードが常にパフォーマンスに影響を与えることを意味しますか? もしそうなら、それはどのくらい重要なヒットですか？