IBM DeveloperIBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
Javaパフォーマンス計測 JITとの闘い - プログラマーの脳みそ
前回の文字列操作編では適当に文字列操作のパフォーマンスを測定しようとしたらGC様とJITコンパイラ様に阻まれた、という話だった。モヒカン族*1が「てめえの計測はなっちゃいねー！ひゃっはー！」と殴りかかったらケンシロウみたいなのが出てきて「あべしっ」となった、ぐらいのつまらない話だったが、反省してこれらと向かい合ってみたい。 JITコンパイラについての情報 JITコンパイラ（Just In Time compiler）とはインタープリタ方式のプログラム言語のランタイムが実行時に必要に応じて部分的にネイティブコード（CPUが直接実行できるマシン語）に変換することで高速化するというコンパイラである。もともとはもっと狭義のニュアンスだったが、今ではJITコンパイルとHotSpot動的コンパイルを併せて広義にJITコンパイル、それを実施する実態をJITコンパイラと呼んでいる感じだ。*2 ただ、やみく
「メモリーを意識してみよう」第4回 進化するメモリー管理：ITpro
先々週にHotSpot VMでのメモリー管理について解説しました。ここでキーとなるのは世代別GCです。 HotSpot VMで世代別GCが採用される以前は，Old領域のGCで使用されるMark & Sweep GCだけでした。世代別GCが導入されたことにより，GCのパフォーマンスは劇的に向上したのです。 しかし，GCの進化はここで終わってしまったのではありません。Java SE 6（開発コード名Mustang）にいたるまで，様々な改良が加えられてきました。 今週はそれらの新しいGCの手法について解説していきます。その前に，まずは基本となるMark & Sweep GCを説明しましょう。 Mark & Sweep GC Mark & Sweep GCは二つのフェーズでGCを行います。 はじめのフェーズで，使用しているインスタンスに印をつけます（Mark，図1a）。Markにはルートインスタン
HotSpot VMの特性を知る
本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 本連載の最終回は、HotSpot VMに固有の振る舞いを学びます。HotSpot VMのデフォルト設定ではパフォーマンスが思うように向上しないケースを紹介し、対処方法を説明します。また後半では、JVMのPermanent領域のチューニング方法を説明します。 ベンチマーク・プログラムからHotSpot VMの特長を探る アプリケーションのチューニングの効果を比較するためにしばしば作成されるのが、簡単なベンチマーク・プログラムです。しかし、HotSpotベースのJVMでは、ベンチマークの設計のまずさが誤解を生む原因となりかねません。例えば、ベンチマークによっては、旧型のJIT（Just-In-Time）コンパイラを備えたClassic
Javaの性能 - Wikipedia
Javaの性能（ジャバのせいのう）では、Javaプラットフォームの性能について説明する。プログラミング言語としてのJavaに対する批判や、Javaプラットフォームの性能に対する批判は「Javaに対する批判」の記事を参照のこと。この記事ではJavaプラットフォームの性能について批判以外の説明をする。 プログラミング言語Javaは、その「ネットワークから送り込まれるプログラムの安全な実行」や「write once, run anywhere」というスローガンを、業界にありがちなスローガンだけのスローガンではなく可能な限り達成するべく、Javaバイトコードにコンパイルするコンパイラと、Javaバイトコードを解釈実行するインタプリタであるJava仮想マシン (Java VM, JVM)、という構成の実装を、公式の実装として伴って発表された。 コンピュータ科学的には特に目新しいものではない。しかし、
Java 6のスレッド最適化は実際に動作しているのか？ - パートII
この記事のパート1(参考記事)では、私たちはシングルスレッドのベンチマークを用いて、同期されたStringBufferと非同期のStringBuilderのパフォーマンスを比較しました。最初のベンチマーク結果では、他の最適化に比べてバイアスド・ロックが最もパフォーマンス向上に役立つ事が判明しました。このベンチマーク結果は、ロックの獲得が高価なオペレーションであると言う事を示唆しているようでした。しかし、そこでまとめに入る前に、私の同僚のマシンでもベンチマークを走らせて、結果の検証を行おうと決めました。ほとんどの結果は私の発見を裏付けるものでしたが、いくつかの結果は完全に異なりました。パート2では、ベンチマークの結果を検証するために用いられるテクニックについてさらに深く見ていきたいと思います。最後に、「なぜプロセッサが異なるとロックのコストも大きく異なるのか」と言う真の疑問に答えます。 ベン
Java 6のスレッド最適化は実際に動作しているのか？
はじめに - Java 6におけるスレッドの最適化 Sun、 IBM、BEAやその他のJVMベンダーが、それぞれのJava 6仮想マシンが提供するロック管理と同期の最適化に多くの注意を払ってきました。バイアスドロック、ロックの粗粒度化、エスケープ解析によるロックの削除、適応型スピンロックといった機能は、すべてアプリケーションのスレッド間でより効果的なオブジェクト共有を可能にし、並列性をより高めるために設計されたものです。こうした個々の機能は洗練されており、興味深いものですが、疑問があります;本当にこうした約束を果たしてくれているのでしょうか？2つのパートからなるこの記事では、私はこうした機能を詳しく調査します。シングルスレッドベンチマークの助けを借りて、パフォーマンスに関する疑問に答える試みをしようと思います。 ロックは悲観的である Java でサポートされているロックの（ほとんどのスレッ
Javaパフォーマンス計測 文字列操作編 - プログラマーの脳みそ
前回でパフォーマンス計測に用いるタイマーについての理解を深めたので、やっとパフォーマンスの計測を始めることができる。 今回のテーマはJavaの文字列連結だ。タイムリーだね。 文字列連結についての基礎知識 Javaの文字列連結についての言語仕様まわりは Stringの連結はそう簡単なものではない - じゅんいち☆かとうの技術日誌 が詳しい。しかし、パフォーマンス計測がなっちゃない。パフォーマンスの計測はそう簡単なものではない。 currentTimeMillis()で計測しておいて plusTime:14780, concatTime:7053, sbuilderTime:7, sbufferTime:13 とか、その7とか13の有効数字はいくつだっての*1。 そんなわけで、計測方法を工夫してみよう。二重ループとし、内側を1000回、それを500回繰り返す。ループが1回まわる間に1回ずつSy
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java 暗号化拡張機能 JDK5.0