土曜にJJUG CCC 2013 Fall(http://www.java-users.jp/?page_id=695)へ行ってきました。 事前にお知らせするのを忘れていましたが、17:15〜18:05のセッションでJVMのソースコードリーディングについてお話ししましたので、発表資料を公開します。 R5-5 JVMコードリーディング入門 〜JVMのOS抽象化レイヤーについて〜 JVMのコードを読みはじめたばかりの方を対象に、JVMとOSのメモリを中心とした関係性についてお話しします。JVMはOSからどのようにメモリを確保しているのでしょうか? そんな素朴な疑問をもとに、JVMのコードを楽しく追いかけてみましょう。※このセッションは入門者向けです。バイトコードやGCについては扱いません。 虎塚 (さくらば組) http://www.java-users.jp/?page_id=709#r5-
あるアプリケーションの作業にとって、スループットは最も重要なターゲットです。1つ例を挙げると、長時間実行されるバッチ処理のジョブです。ガベージコレクションが実行されている間、バッチジョブが時々1、2秒止まっても、ジョブ全体がすぐに完了すれば問題ありません。 人間が直接対話するアプリケーションから金融取引システムまで、実質的な他のすべての作業では、システムが1、2秒か、数ミリ秒以上反応しない場合、大変なことになり得ます。金融取引では、しばしば一貫した停止時間と引き換えに、スループットを犠牲にするだけの価値はあります。物理的に利用可能なメモリ量によって制限されるアプリケーションを持ったり、footprintを維持しなければならなかったりすることもあります。そのような場合、停止時間とスループットの面の両方で、パフォーマンスをあきらめなければなりません。 以下のトレードオフは度々起こります。 大部
あのWebサービスもJVMを利用している 「Javaは大規模なエンタープライズシステムにしか使われない」 それが常識だと思っていませんか? たしかに、これまでJava Virtual Machine(JVM)は、他の言語を実行すると遅く、Javaのプログラムを実行する環境にすぎないものでした。ところが、Java 7から実装されたInvokeDynamicにより、JVM上で、RubyやPHPなどさまざまなコンピュータ言語で記述されたプログラムをより高速に実行できるようになりました。 これにより、今までエンタープライズでJava言語で記述されたプログラムを実行するだけの環境であったJVMが、汎用的な実行環境になったと言えます。また、これまでJavaの実行環境として使用されていたノウハウが、他の言語で記述されたプログラムを実行する際にも利用できます。 最近では、TwitterがJVMをアプリケー
HBaseのJuliet PauseをきっかけにしてGarbage Collection(以下GC)についてちょっと調べてみました。そういえば長年Javaでお仕事している割にはGCのこと全然知らなかった(汗 GCというのは不要になったメモリを回収することをいいますがそのアルゴリズムにはいくつかあって代表的なものとして以下の2つがあります。 Mark Sweep GC Coping GC Mark Sweep GCはオブジェクトをアプリケーションからたどっていってMarkしていきます。Markが無いのは使われていないオブジェクトなのでSweepします。メリットは実装が簡単なことでデメリットはメモリの断片化、フラグメンテーションが起きることです。 Coping GCはヒープ領域を2つに分けてオブジェクトをコピーしたり移動したりすることです。メリットはスループットが高いことやフラグメンテーション
The Big Guns get behind mlvm. I mean, BIG like GE, and Facebook! "Are interpreters immoral?" A question I posed some months ago which might soon become irrelevant. General purpose interpretors are about to go the way of general purpose punch cards! Facebook are looking to move PHP on. Why, because clock cycles cost money. Their first approach was hiphop, a PHP to C+++ cross compiler. Now they are
MugはJavaScriptのコードをコンパイルしてJavaの中間コードにしてしまうソフトウェアです。 ここ最近、プログラミング言語同士の壁が徐々に破壊されている気がします。あるプログラミング言語上で別なプログラミング言語を動くようにしたり、置き換えてしまったりするような類です。今回はその一つ、JavaScriptをJavaVM上で動かすという、かなり無茶な気がしなくもない、そんなソフトウェアMugを紹介します。 元コードです。 コンパイルしました。 実行しました。確かに出力されています。 デモ2です。確かにJavaScriptです。 こちらもJVM上で実行されています。 MugはシンプルかつスタティックなJVMのためのJavaScriptコンパイラーです。書き方に多少の特徴はありますが、コードはあくまでもJavaScriptです。それをコンパイラを使ってclassファイルにします。その結
Twitterがフロントエンドのアーキテクチャを見直し、Webページの読み込み速度を改善したことをブログで明らかにしています。 新しいアーキテクチャでは、これまでWebブラウザ上でJavaScriptの処理によって行ってきたWebページのレンダリングを見直し、サーバ側でレンダリング済みのHTMLページを送信し表示することにしています。これによってWebページの読み込みから最初のツイートの表示までの時間が大幅に短縮されることになりました。 When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’
JavaVMをJavaScript/ECMAScript5対応にする「Nashorn」、JDK 8でリリース。Node.jsとの連係をオラクルがデモ オラクルが開発中の「Nashorn」は、JavaVMでJavaScriptを実行可能にするソフトウェア。その詳細が4月4日と5日に六本木で開催されたJavaOne Tokyo 2012のセッション「The Future of JavaScript in the JDK」で明らかにされました。 JavaVM上のJavaScriptエンジンとしてはMozillaが開発したオープンソースのRhinoがすでにありますが、Nashornはオラクル社内のプロジェクトとして新しく書き起こしたJavaScriptエンジン。Java 7で加わったInvoke Dynamicsなどの新機能も活かした「2012年におけるRhino」(セッションの講師でNashor
4/4-5 に行われた JavaOne Tokyo 2012 の JVM言語BoFに、スピーカーとして参加してきました。 BoFの概要は以下のような感じです。 JavaVM上で動作するさまざまなプログラミング言語 (Groovy、JRuby、Scalaなど) のコミュニティや興味を持つ個人が集まって、各言語のチュートリアルや最新情報、使用実績などの情報交換を行います。プレゼンテーション、各言語を使ったコーディング大会、ライトニング・トークなどの形式で、ユーザ間の交流を促すBoFとして開催し、言語を超えて活用が進むJavaVMの日本ユーザの裾野を広げます。飛び入り参加大歓迎、楽しい時間にしたいと思います。 https://oj-events.jp/public/session/view/173 僕は ScalaJP からコーディング大会の Scala 担当として発表させて頂きました。 あのじ
You can still play with the last VMKit release, but the project is not more maintained. Moreover, the information on these pages may be out of date. If you are interested in restarting the project, please contact Gaël Thomas Current MREs are monolithic. Extending them to propose new features or reusing them to execute new languages is difficult. VMKit is a library that eases the development of new
7/19〜21にサンタクララのOracleオフィスで JVM Language Summitというイベントが開催されていました。 http://openjdk.java.net/projects/mlvm/jvmlangsummit/ そこで発表された、JetBrainsのKotlinというJVM言語が、かなりイイ感じです。 http://www.wiki.jvmlangsummit.com/images/6/6e/Jetbrains-Kotlin.pdf http://confluence.jetbrains.net/display/Kotlin/Welcome 「ことりん」っていう、AKBにいてもおかしくない可愛い名前はもちろんのこと、 JVM上で動く、静的型付けな、今風の簡潔に書ける言語でありつつ、 文法がかなりJavaに近いところが良いですね。 開発元がJetBrainなことも、エ
Gavin King, the Hibernate Java ORM famous creator was busy lately developing Ceylon … a new JVM language that suppose to be a Java KILLER. Bellow is Gavin King’s presentations given at QCon Beijing 2011 Introducing the Ceylon Project The Ceylon Type System References: – Ceylon – by Gavin King – Red Hat Uncloaks ‘Java Killer’: the Ceylon Project – Gavin King unveils Red Hat’s top secret Java Killer
※当記事はNAVERまとめに移行しました。(2012-04-14) 今後はNAVERまとめの方でメンテしてゆきますので、 よろしくお願いします。 JVM (Java Virtual Machine)上で動くプログラミング言語が増えてきたのでここらへんでまとめて行きたいと思います。新しいのを見つけ次第追加して行きます。 こんなのもあるよ!といった情報は大歓迎です。コメントかはてブコメントにてよろしくお願いします。 JVM上で動くプログラミング言語一覧 ※はてブエントリ数順*1 No. 言語名 Wikipedia 説明 1 Scala (ja,en) オブジェクト指向+関数型のハイブリット言語。TwitterやFacebookなどもバックボーンにScalaが使われている。 2 Noop (ja,en) Noop (発音 /ˈnoʊ.ɒp/) は新しいプログラミング言語を開発することを意図するG
GCを適切に行わせるためのヒープサイズの設定 JVMにGCを適切に行わせるにはヒープサイズを適切に設定(New領域サイズ、Old領域サイズ、領域サイズのバランスなど)する必要があります。当然、適切なヒープサイズはアプリケーションに依存します。一般にヒープサイズが小さいとGCが頻発してアプリケーションのパフォーマンスが低下します。さらに、ヒープサイズが必要量を下回る場合はOutOfMemoryErrorが発生してアプリケーションが停止してしまいます。一方、ヒープサイズが大きいと、GCの起動回数は減りますが、GC1回当たりの処理時間、すなわちアプリケーション停止状態が長くなり、アプリケーションの応答時間に問題が出る場合もあります。システムの物理メモリのフリー領域が不足するまでヒープサイズを大きくすると、物理メモリからスワップ領域へのページングが起こってしまい、かなりのパフォーマンスが劣化する可
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く