はてなブックマーク

Java SE 6 な JVM の Oracle 実装（いわゆる元 Sun の Hotspot VM）Update 14 のタイミングで、64 ビット版で UseCompressedOops というオプションが使えるようになりました。本オプションの技術的概要については、下記サイトとか参照してください。 UseCompressedOops - Hotspot JVMの圧縮OOP ものすごく単純に言ったバージョンは、Update 14 のリリースノート参照。 http://java.sun.com/javase/ja/6/webnotes/6u14.html -XX:+UseCompressedOops オプションを使用すると、Java オブジェクトヒープのサイズが 32 ギガバイト未満の場合に、64 ビット JRE のパフォーマンスを向上させることができます。この場合、HotSpot はオブ

お仕事で VMware vFabric GemFire（以下、単に GemFire）を弄りはじめて一ヶ月ほどたったので、日本語のリソースもあまりなさそうなのでちょっとまとめてみる。 ＃なお、個人的な主観・推測がたぶんに含まれているので話半分なブログエントリということでお願いいたします。 GemFire って何ですか？ はやりの言葉で一口にいうと、Java ベースの NoSQL なインメモリ型 KVS だけど、そういったバズワードが流行る以前から「データグリッド製品だよ」みたいなカテゴライズがされていて、似たような製品の Oracle Coherence とともに金融市場系システムで鍛えられてきただけあって、以下のような機能もサポートしています。さすが商用製品。 トランザクションが話せる（JTA 対応） Key・Value として Java オブジェクトをつっこめるオブジェクトサーバの側面も

以前から、Windows Vista 環境において、デフォルトで動いている MS の Windows Search サービスのデスクトップサーチインデックスが何かのタイミングでリセットされて再構築される現象に悩まされておりました。何日もかけて数十万個のサーチインデックスを作成し、そして再構築されるんです。Outlook の検索が表示されなくなるは、インデックス作成のためずっとディスクアクセスしてパフォーマンスは落ちるわで非常に迷惑しておりました。 ずっと原因を模索しておりましたが、本日、何もしてないのにいつのまにかまたインデックスがリセットされて、またはじめから作り直しているアホな Windows Search サービスがそこにいたので、ブッ殺しました。そして、気がついたらそこには Google Desktop がインストールされてました。また、Google 依存度があがってしまいました。

[rakuten:book:10975686:detail] Java 仮想マシン仕様 4.10 節に制限事項があります。これらのひとつが、1 メソッドの最大サイズは 65,536 バイト（64KB）という制限。こちら。 The amount of code per non-native, non-abstract method is limited to 65536 bytes by the sizes of the indices in the exception_table of the Code attribute (§4.7.3), in the LineNumberTable attribute (§4.7.8), and in the LocalVariableTable attribute (§4.7.9). Java 言語で普通にコーディングする方々から見ると「1 メソッ