9月の頭くらいに、Javaのリリースモデルが6ヶ月ごとの短期リリースになるということが発表されてました。 で、「へぇ〜」みたいな感じで見てたのですけど、JavaOneでの話を聞くと、これ結構大変なのかも、ということになってそうなので、ちょっとまとめてみます。 追記：2018年05月の状況をQiitaでまとめています。 [Javaのサポートについてのまとめ2018 - Qiita](https://qiita.com/nowokay/items/edb5c5df4dbfc4a99ffb) Javaの新しいリリースモデル 公式情報はこちらにまとめられています。(10/4にアップデートされてます) http://www.oracle.com/technetwork/jp/java/eol-135779-ja.html ざっくり言えば、6ヶ月ごとに機能リリースを行い、3ヶ月ごとにメンテナンス/セキ
こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
一昨年に出版されたImplementing Programing Languages <http://www.digitalgrammars.com/ipl-book/> という本（以下IPL）を読んでいました。 この本は名前の通りインタプリタ/コンパイラの実装についての本ですが、とてもいい本です。何がまずいいかというと、薄い（そして安い）。207ページしかありません。コンパイラ作りたいとなったらドラゴンだのタイガーだのと格闘しなければならないという先入観がありますのでこの薄さは画期的です。 内容の深さという意味では他の本に譲る点はあるのでしょうが、一通りのことが実践できるようになるまでを要領よく解説していて、かつ最初は読み飛ばしてもいい理論部分にもわざわざ印をつけてくれているので、おそらくコンパイラ作成志望者にとっての最短コースを示してくれる本だと思います。 飛ばし読みの成果としてJVM
The Chronon Time Travelling Debugger allows you to playback Chronon recordings of your Java programs and easily find root cause of defects. It is specifically built from the ground up to allow debugging of long running programs that run for days/months and are highly multithreaded. The debugger plugs seamlessly into Eclipse adapting itself naturally to your workflow. You can also use the Eclipse i
Legacy Java EE Home The Java EE project has been contributed to Eclipse Foundation and has been renamed to Jakarta EE. All active work is taking place at this new location https://projects.eclipse.org/projects/ee4j https://jakarta.ee/specifications The following legacy archives are available for anyone who wishes to browse the extensive history, prior to contribution to Eclipse. Key Java EE resour
OpenJDK や Hotspot VM には sun.misc.Unsafe という内部APIがあり*1、これを使うと ByteBuffer.getInt や ByteBuffer.getLong よりも高速にバイト列から整数値をデコードできるという。これを駆使することで、Cで実装された拡張ライブラリに匹敵する速度を出せるらしい。 それが本当なら、データ圧縮やハッシュ関数、シリアライザ/デシリアライザなどの実装を高速化できる。例えば、lz4 や xxhash のJava実装が Unsafe API を使用している*2：jpountz/lz4-java Prestoも、中間データのシリアライズ/デシリアライズにはすべて Unsafe API を使っている*3。 そこで、実際にベンチマークしてみた。 ベンチマーク内容 10MBのランダムなバイト列を生成する 先頭から1バイト読み出す その1バ
README.md c[_] Mug 0.2, easy JavaScript for your JVM Mug is a simple, static JavaScript compiler for the JVM, written in CoffeeScript (and self-hosted!). Mug targets Java 6 and focuses on simplicity and file size. Getting Started $ git clone git://github.com/timcameronryan/mug.git mug $ cd mug/mug-compiler/test $ export CLASSPATH=../mug-runtime-0.2.0-jar-with-dependencies.jar:../asm-3.3.jar:../lib
Java仮想マシンのシミュレータがほしくなったので仮実装。 未実装のニーモニックが多数ありますが、初期状態で入力されているHello, worldは動作します。フルスクリーン推奨。 バイトコードをテキストとして書く場合の書式についてはJasminの書式を流用中。 http://jasmin.sourceforge.net/instructions.html 簡単な使い方説明とかはこちら。 http://d.hatena.ne.jp/eller/20110322#1300795939 ★NEW!★ スタックが目視できる新バージョンを実装しました。 http://jsdo.it/eller86/jvms2 // 参考：JVM仕様書第2版 // http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html va
1. わかる !Java バイトコード ― 30 分でわからない ?Java バイトコード入門 筑波大学大学院 システム情報工学研究科 博士後期課程 水島宏太 2. 自己紹介とか Twitter: @kmizu はてな : id:kmizushima github: http://github.com/kmizu/ 大学院生 構文解析の研究とかやってます 特に Packrat Parsing Scala 好き Scala の布教活動をあちこちでやったり JVM 好き JVM 上で動作する言語処理系 Onion を開発 3. Agenda プログラミング言語としての Java バイトコード マシンモデル 型システム 命令セット クラスファイルベリファイア ベリファイアがはじく操作の例 簡単なプログラムを javap で逆アセンブルする 役に立つかもしれない javap のオプション解説 クラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
