タグ

jvmに関するtarchanのブックマーク (18)

  • OpenJDK 16のShenandoahガベージコレクション:並行参照処理 - 赤帽エンジニアブログ

    Red Hat で Solution Architect として OpenJDK を担当している伊藤ちひろ(@chiroito)です。 この記事は、Red Hat Developerのブログ記事、Shenandoah garbage collection in OpenJDK 16: Concurrent reference processing | Red Hat Developer の翻訳記事です。 OpenJDKにおけるShenandoahガベージコレクション (GC) プロジェクトの主の動機は、ガベージコレクションの停止時間を短縮することでした。参照処理は、伝統的にGCの停止の主な原因の1つでした。この関係はほぼ一次式です。つまり、アプリケーションがより多くの参照を処理すればするほど、ガベージコレクションの停止と遅延への影響は大きくなります。ここで重要なのは「処理」、つまりGCサイ

    OpenJDK 16のShenandoahガベージコレクション:並行参照処理 - 赤帽エンジニアブログ
  • Apache Kafkaで発生した原因不明のパフォーマンス低下と、それを解決するためにやったこと

    2019年7月17日、kafka.apache.jpが主催するイベント「Apache Kafka Meetup Japan #7」がLINE株式会社にて開催されました。分散ストリーミングプラットフォーム「Apache Kafka」に関するナレッジや最新情報を共有するイベント。今回は4人のエンジニアが、自身や自社における知見を語りました。プレゼンテーション「Kafka Broker performance degradation by mysterious JVM pause」に登壇したのは、LINE株式会社の河村勇人氏。ある日Kafkaに起こった突然のパフォーマンス低下とその原因について、解決までの軌跡を語りました。講演資料はこちら Apache Kafkaのパフォーマンス低下とその原因 河村勇人氏:よろしくお願いします。最初に自己紹介をします。河村勇人といいます。 LINEで全社向けの

    Apache Kafkaで発生した原因不明のパフォーマンス低下と、それを解決するためにやったこと
  • Jvm internal

    JDK 16 で導入された JEP 396 にご注意!! (JJUG CCC 2021 Spring)

    Jvm internal
  • Javaはどのように動くのか~図解でわかるJVMの仕組み 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    Javaはどのように動くのか~図解でわかるJVMの仕組み 記事一覧 | gihyo.jp
  • JVMのオススメ起動オプション - oinume journal

    なんか秘伝のタレみたいになってきたので後世のために共有。 前提 Webアプリケーションを想定 TomcatなりJettyなりがListenするポートは外部からはアクセスできない ※-Xms -Xmx -Xmn あたりは搭載しているメモリ容量によって変える、-XX:MaxPermSize -XX:PermSizeは384mあれば十分だと思うけどロードするクラスの数次第なので要調整。 NOW=`date "+%Y%m%d-%H%M%S"` JAVA_OPTS="-server -Xms2g -Xmx2g -Xmn1g -XX:MaxPermSize=384m -XX:PermSize=384m \ -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=85 -XX:MaxTenuringThreshold=32 \ Javaプログラマーなら習得しておきたい J

    JVMのオススメ起動オプション - oinume journal
  • GC ログに関わる JVM コマンドラインオプションまとめ - 理系学生日記

    Full GC による Stop the World でサーバが停止状態に…、そんなときに調査の助けになるのが GC のログ。Permanent 領域が溢れているのか、Java Heap が溢れているのか、Heap が溢れているのなら何のオブジェクトが溢れているのか、メモリリークが発生しているのか。それが分からないと何気に対処のしようがない。 ただ、この GC のログ、それなりの設定をしておかないと解析に耐えないし役に立たない。役に立たないログ出力はディスク容量を圧迫するゴミになる。そういう感じのログを目にして、なんとかならんもんかなー、なんとかせねばなーと検討しており、Oracle のページからそれっぽいオプションを調べてみてる。 Java HotSpot VM Options 当然ながら「Oracle のページ」と書いてあるように、Oracle の JVM が対象であって、他の JVM

    GC ログに関わる JVM コマンドラインオプションまとめ - 理系学生日記
  • JJUG CCC 2013 Fall「JVMコードリーディング入門」資料公開 - 虎塚

    土曜に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-

    JJUG CCC 2013 Fall「JVMコードリーディング入門」資料公開 - 虎塚
  • ScalaのFunction22問題(またはTuple22問題)について思うこと - たけぞう瀕死ブログ

    Scalaで実際にシステム開発を行う上でかなりの高確率で遭遇するのがFunction22問題(またはTuple22問題)です。Scala Conference in Japan 2013のセッションではScalaの問題点として挙げたのですが、実際はいろいろと思うところもあるので書いておきます。 Function22問題(またはTuple22問題)とは? Scalaのフレームワークではケースクラスへの値のマッピングにタプルを使ったり、値のバインドやアンバインドにapplyメソッドやunapplyメソッドを使うものが多いのですが、Scalaには以下のような制約があるため、22個以上のプロパティを定義することができない、というものです。 22個以上の引数を持つ関数を作ることができない(メソッドとしては定義できますが、変数に代入したり関数渡しをしようとするとコンパイルエラーになります) 要素が22

    ScalaのFunction22問題(またはTuple22問題)について思うこと - たけぞう瀕死ブログ
    tarchan
    tarchan 2013/03/12
    >引数の22個以上の引数を持つ関数を作ることができない(メソッドとしては定義できますが、変数に代入したり関数渡しをしようとするとコンパイルエラーになります)
  • 3/11(月)〜3/24(日)のJava/JVM関連の勉強会・イベント | yusuke.blog

  • 第1回 JVMはどのようにメモリ空間を利用するのか | gihyo.jp

    あのWebサービスもJVMを利用している 「Javaは大規模なエンタープライズシステムにしか使われない」 それが常識だと思っていませんか? たしかに、これまでJava Virtual Machine(JVM)は、他の言語を実行すると遅く、Javaのプログラムを実行する環境にすぎないものでした。ところが、Java 7から実装されたInvokeDynamicにより、JVM上で、RubyPHPなどさまざまなコンピュータ言語で記述されたプログラムをより高速に実行できるようになりました。 これにより、今までエンタープライズでJava言語で記述されたプログラムを実行するだけの環境であったJVMが、汎用的な実行環境になったと言えます。また、これまでJavaの実行環境として使用されていたノウハウが、他の言語で記述されたプログラムを実行する際にも利用できます。 最近では、TwitterがJVMをアプリケー

    第1回 JVMはどのようにメモリ空間を利用するのか | gihyo.jp
  • vert.x – Node.jsの代替フレームワーク

    Vert.xは次世代の非同期でスケーラブルな並列処理アプリケーションのためのフレームワークでありJVM上で動作する。Node.jsの代わりになり得るフレームワークだ。開発者はJavaScriptRuby、Groovy、Javaを使ってこのフレームワーク向けのアプリケーションを作れる。これらの言語を混ぜ合わせて使うことも可能だ。 下記はvert.x上で動作するウェブサーバが静的なファイルを提供する場合のコードだ。 // JavaScript load('vertx.js') vertx.createHttpServer().requestHandler(function(req) { var file = req.path === '/' ? 'index.html' : req.path; req.response.sendFile('webroot/' + file); }).list

    vert.x – Node.jsの代替フレームワーク
  • @IT:Javaパフォーマンスチューニング 第3回

    記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの

    @IT:Javaパフォーマンスチューニング 第3回
  • 「メモリーを意識してみよう」第1回 ヒープがどのくらい使われているかを理解する

    Javaのメモリーはガーベジ・コレクタが管理するため,アプリケーション側ではそれほど気にするありません。しかし,全く気にしないわけにはいかないのも実情です。 小さいアプリケーションでは無頓着であっても構いませんが,大規模になればそうもいってはいられません。使用メモリー量,ガーベジ・コレクション(GC)の頻度,リークの有無などは,できればチェックしておきたい項目です。 Javaではメモリーを複数の領域に分割して管理しています。クラス定義やメソッドなどのデータが格納されるPermanent領域や,インスタンスが割り当てられるヒープなどがあります。このような領域がどのように使用されているかを知ることは,パフォーマンスを考えるうえでもとても重要になります。 ここでは,特にヒープに着目していきたいと思います。 ヒープの使用量を知る まずはヒープの使用量がどのくらいになっているかを調べてみましょう。

    「メモリーを意識してみよう」第1回 ヒープがどのくらい使われているかを理解する
  • 【コラム】イマドキのIDE事情 (79) Java VMの監視/障害解析に役立つツール | エンタープライズ | マイコミジャーナル

    トラブルの発生時に利用するツール システム開発の現場では予期しないトラブルが付き物だ。Javaの場合、ヒープメモリやGCに関するトラブルが発生することが多い。この場合、GCログやヒープダンプを解析することで原因の特定を試みることになる。今回はこれらのトラブルが発生した場合に役立つツールを紹介する。 JDK標準ツール「jconsole」 jconsoleはJDKに標準で付属するJMXクライアントツールで、Java VMのリソースの利用状況を監視するのによく利用される。JDKインストールディレクトリのbinディレクトリ配下のjconsole.exeで起動することができ、ローカルで動作しているプロセスのほか、リモートで動作しているJava VMに接続することも可能だ。JDKのインストールディレクトリ直下のbinディレクトリにあるjconsole.exe(Windowsの場合)で起動することができ

  • Javaプラットフォームを進化させるJRuby - @IT

    「JVM上で不可能なことなど何もない」(Nothing is impossible on the JVM)――、こう話すのはJRubyでコア開発メンバーを務めるチャールズ・ナッター氏だ。2009年6月1日、米国サンフランシスコで開催されたCommunityOne(JavaOne)で講演したナッター氏は、JavaVM上にRuby処理系を実装した経験について話した。当初まったく実現不可能に思えたプロジェクトで、どう障害を乗り越え、その取り組みがいかにJavaプラットフォームに影響を与えているかについて解説した。講演のタイトルは「不可能を超えて:JRubyはいかにJavaプラットフォームを進化させたか」(Beyond Impossible:How JRuby Has Evolved the Java Platform)だ。 Ruby on JVM!? そんなの実現不可能! もともとJava言語向

  • InfoQ: JVMで動く言語Ioke:分かりやすい構文で、LispとRubyの力を持つ言語

    Ola Bini氏(リンク)は、JRuby (リンク)開発の中心人物であり、Practical JRuby on Rails Projects(リンク)の著者である。その彼が、Ioke(リンク)というJVMの上で動く新しい言語を開発している。Iokeの型を重視し、非常に動的でプロトタイプベースのオブジェクト指向言語が目指すところは、素晴らしいぐらい小さい正規構文を持つLispやRubyを使用したときに得られる同等の力を開発者に授けることである。 Ola氏は、以下にIokeの質(リンク)に関する説明をしている。 Iokeは、強力な型付け言語であり、動的、プロトタイプベースのオブジェクト指向言語です。それは同図像であり、数種類のマクロがビルトインされています。Iokeに最も影響を与えた言語は、Io(リンク)、Smalltalk(リンク)、Self(リンク)、Ruby(リンク) そしてLisp

    InfoQ: JVMで動く言語Ioke:分かりやすい構文で、LispとRubyの力を持つ言語
  • 開発者が知っておくべきJavaと仮想マシンの歴史

    Javaの黎明(れいめい)期、多くの人々にJavaが知られ、広まった理由の1つは、WebブラウザにJava VMが組み込まれたことにあるでしょう。その当時のWebブラウザ開発のエキサイティングな様子は、雑誌『Wired』の古い記事「The Java Saga」で読むことができます。 Webブラウザ上で動作するJavaアプレットの勢いも借りて、各OSベンダが米サン・マイクロシステムズからライセンス提供を受け、各OSプラットフォーム用のJava環境が続々とリリースされます。 その一方、米マイクロソフトのWebブラウザ「Internet Explorer」(以下、IE)にJava VMが組み込まれたことは、歓迎とともに混乱を招きました。米マイクロソフトが提供したWindows 95/NT用のJava VM((MSJVM))が持つ「J/Direct」機能は高性能ながら、Win32 APIを直接呼び

    開発者が知っておくべきJavaと仮想マシンの歴史
  • The Scala Programming Language

    val fruits = List("apple", "banana", "avocado", "papaya") val countsToFruits = // count how many 'a' in each fruit fruits.groupBy(fruit => fruit.count(_ == 'a')) for (count, fruits) <- countsToFruits do println(s"with 'a' × $count = $fruits") // prints: with 'a' × 1 = List(apple) // prints: with 'a' × 2 = List(avocado) // prints: with 'a' × 3 = List(banana, papaya)

    The Scala Programming Language
  • 1