タグ

jvmに関するakishin999のブックマーク (70)

  • Scalaはもうだめなのか?…というかJVM言語がもうだめじゃん?|sugitani

    AndroidのためのJava/Kotlinはスコープ外とします まず断っておくと、俺はScalaが好きだ。 自分が作ったScalaプロダクトは二個現存している。うち一つはまだまだ自分が開発している。というか今は会社を作って1人でプロダクトを作っている身なのだが、それもScala3+ZIO2でゴリゴリ書いている。 でも残念、もうScalaというかJVM言語がオススメできません。TypeScriptGoRustをオススメします。 どういうこと?まずこの記事を見ていただくのが一番分かりやすい。 https://aws.amazon.com/jp/builders-flash/202310/java-serverless-saas-backend/?awsf.filter-name=*all 素晴らしいエントリーだ。読みに行かないせっかちな方のために概要を紹介する JavaプロダクトをAWS

    Scalaはもうだめなのか?…というかJVM言語がもうだめじゃん?|sugitani
  • Java 言語仕様・JVM仕様のバージョンごとの差分を見れるページを作りました。 - Qiita

    世界 30 億の Java エンジニア向けに、Java 言語仕様・JVM仕様のバージョンごとの差分を見れるページを作りました。 The Java Language Specification diffs The Java Virtual Machine Specification diffs ぜひご利用ください! なにこれ? Java の各バージョンごとの言語仕様・JVM仕様はこちらのページで公開されています。 Java Language and Virtual Machine Specifications ただ、バージョンごとの変更点がありませんでした1。 そこで、各ページからテキストを抜き出して2、GitHub 上で差分が見れるようにしました。 更新について 細かい誤字脱字の変更とかを除いた差分が作れるとより良いのですが、そうすると今後の更新に手間がかかってしまいまそうでした。 それよ

    Java 言語仕様・JVM仕様のバージョンごとの差分を見れるページを作りました。 - Qiita
  • TOMCAT殺害事件 - Qiita

    OOMKillerの殺意 顧客EC2のTomcatがアクセスの無い早朝にもかかわらずOOMKillerに突然殺されてしまったので、調査した顛末をたぶん同じような問題に直面されている方もおられるかと思いますので備忘録として記載します。 Javaヒープのチューニングにも多少役立つかと思います。 (この記事はJava8が対象となります。) OOMKillerとはOut of Memory時に、サーバ全体を守るためにメモリーを消費しているプロセスを停止するLinuxの標準機能です。 そのOOMKillerになんとTomcatが突然殺害されてしまいました。 問答無用の辻斬り状態です。 早朝ですのでアクセスログには何も記録されておらず、catalina.outには OpenJDK 64-Bit Server VM warning: Setting LargePageSizeInBytes has no

    TOMCAT殺害事件 - Qiita
  • JVM の DNS キャッシュを制御する - 平常運転

    JVM (Java 仮想マシン) には DNS の名前解決の結果をキャッシュする挙動が備わっている。キャッシュするだけならいいのだけれど、このキャッシュでは DNS の TTL を無視してキャッシュするため、名前解決の結果が変わっても JVM からの接続先が切り替わるまでに(TTL から想定される時間以上に)時間がかかる、あるいは全く切り替わらないということがある。この挙動やその制御について調べたので、その話をする。 (以下の話題では Oracle JDK および OpenJDK を対象にして論じるので、それ以外の JVM 実装でどうなってるかは調べていない。適用できる箇所もあればそうでない箇所もありそう) 背景・解説 これらのデフォルト値は名前解決成功時は セキュリティーマネージャーがインストールされている場合のデフォルト値は -1 (ずっと) で、セキュリティーマネージャーがインストー

    JVM の DNS キャッシュを制御する - 平常運転
  • JVMのGCイベントのログをSlf4j経由でJSON形式でログとして出す | DevelopersIO

    こんにちは。生魚美味しいですよね。今日久しぶりにべましたが、やっぱり美味しい。 どうも齋藤です。 今回はGCイベントのログをSlf4j経由で出力してみたいと思います。 また、JSON形式でログを出力してみましょう。 今回作ったアプリケーションは以下のリポジトリにコードを置いております。 gclogger はじめに JVMのGCログは来オラクルのサイトの記述を参考にすると -verbose:gc もしくは -Xloggc:filename を指定することで、標準出力もしくはファイル出力することができるようです。 しかし、アプリケーションのログ等ではSlf4jなどを使われているのではないでしょうか。 この記事では、JVMのGCイベントのログをSlf4j経由で出力してみます。 また、この記事で書いたログで出力される内容は、JVM体から出力されるGCログとは少し違う内容になります。 今回は、

    JVMのGCイベントのログをSlf4j経由でJSON形式でログとして出す | DevelopersIO
  • JPHP - JavaVM上で動くPHP

    MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました PHPは15年以上前に登場し、今なおWebアプリケーションのトップシェアを誇るプログラミング言語です。それだけに開発者人口も多く、もっと他の場面でもPHPを使っていきたいと考えている人も多いのではないでしょうか。 今回はJPHPJavaVM上に構築されたPHP実行エンジンを紹介します。新しいPHPの使い方が見えてくるかも知れません。 JPHPの使い方 JPHPを実行します。gradleを使うのが楽です。 $ gradle run :compileJava UP-TO-DATE :processResources :classes :run Hello World BUILD SUCCESSFUL Total time: 2.966 secs This build could be

    JPHP - JavaVM上で動くPHP
  • Web Application Server を動かす時の Java8 起動オプションのメモ - その手の平は尻もつかめるさ

    一般的な Web Application Server *1 を Java8 で動かすにあたって,最近有効にしている起動オプションについてメモ. 何か間違っていたり,あるいは「こっちの方が良い」みたいなのがあれば教えて下さい. -server server mode で起動させる (指定しないと client mode になる可能性がある,マシンスペックによってスイッチする?). -Djava.net.preferIPv4Stack=true If IPv6 is available on the operating system the underlying native socket will be an IPv6 socket. This allows Java(tm) applications to connect too, and accept connections from,

    Web Application Server を動かす時の Java8 起動オプションのメモ - その手の平は尻もつかめるさ
  • 俺の Jolokia チートシート | iret.media

    ども、cloudpack の かっぱ (@inokara) です。 も少し Jolokia について掘り起こしたいと思いますので、こちら「Chapter 6. Jolokia Protocol」を参考にとりあえずチートシートっぽいのを書いていきます。尚、MBean 等の用語の使い方に誤りがあるかもしれませんので、その際にはご指摘頂けると幸いです。 リクエスト とりあえず… <base-url> は http://localhost:8778/jolokia とします。ポート番号については Jolokia を起動する際に変更することが可能です。前回の記事では以下のように環境変数 ES_JAVA_OPTS に設定して Elasticsearch を起動していますので、ポート番号は 8778 番で Jolokia は Listen することになります。 ES_JAVA_OPTS="$JVM_OP

    俺の Jolokia チートシート | iret.media
  • 恐怖の JVM 大量メモリ消費!メモリリークの謎を追え!! - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、

    恐怖の JVM 大量メモリ消費!メモリリークの謎を追え!! - Cybozu Inside Out | サイボウズエンジニアのブログ
  • Server::Starter から簡単に Java プロセスを起動できるようになった - tokuhirom's blog

    JVM には inetd から起動するときのために、file descriptor 0 をソケットとして開く機能がついている。Jetty 等もこの機能に対応しているので、簡単に利用できる。 file descriptor を 0 に固定出来る機能が Server::Starter にあればよかろうということで、以下のような指定で起動できるように実装した。 $ start_server --port=20000=0 java EchoServer この機能により、Java も LL と同様な形態でアプリケーションを運用することが可能となる。 Java では昔から ClassLoader 機構を利用することによりホットデプロイを行うことが可能だが、リソースの解放が漏れるなど開発時の難しさが指摘されている。 Server::Starter 方式では JVM のプロセスごと死ぬので、綺麗な状態で都

  • ダブルチェックの代わりに・・・ - Shammer's Philosophy

    JSR 133に、Javaのメモリモデルについての情報がある。 そして、この情報は和訳されている様子。 http://www.javareading.com/bof/cookbook-J20060917.html reorderとか、volatileの話など、かなりマニアックな情報だ。 さらに、FAQの話もある。先のダブルチェックはNGという話もここに情報が・・・ http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html このようにすれば、複数スレッドからアクセスされても安全な実装になるらしい。 public class InitializeOnDemandHolder { private static class LazyHolder { public static InitializeOnDemandHolder sin

    ダブルチェックの代わりに・・・ - Shammer's Philosophy
  • Javaのプログラムはどうやって動いているの? JVM編

    Yahoo! JAPANのIaaS基盤では200超のOpenStackクラスタが稼働しており、それらのコントロールプレーンをKubernetes上にデプロイしています。IaaSチームで管理している十数のKubernetesクラスタは古いバージョンのまま運用が続けられていたため、現在、段階的にバージョンアップおよびその自動化に取り組んでいます。このようなクラスタ群をメンテナンスする中で、工夫した点や失敗した点、得られた知見を紹介します。 Yahoo! JAPAN Tech Conference 20222022年2月3日、4日に開催しました。 https://techconference.yahoo.co.jp/2022/ アーカイブ動画はこちらからご覧ください。 https://youtu.be/F5EQqWOw8So

    Javaのプログラムはどうやって動いているの? JVM編
  • ふわっと JVM のヒープ領域監視について考える - ようへいの日々精進XP

    ども、かっぱです。 はじめに Java アプリケーションを運用する上では避けて通れないであろうヒープ領域の監視についてフワッと考えてみた JVM には幾つか領域があるがヒープ領域に焦点を当てる 参考 http://www.whitemark.co.jp/tec/java/javaHeap.html http://www.whitemark.co.jp/tec/java/javagc.html http://d.hatena.ne.jp/ogin_s57/20120623/1340463194 http://d.hatena.ne.jp/ogin_s57/20120709/1341836704 https://docs.oracle.com/javase/jp/1.5.0/guide/management/agent.html http://chonaso.hatenablog.com/en

    ふわっと JVM のヒープ領域監視について考える - ようへいの日々精進XP
  • 恐怖の JVM 大量メモリ消費!メモリリークの謎を追え!! - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、

    恐怖の JVM 大量メモリ消費!メモリリークの謎を追え!! - Cybozu Inside Out | サイボウズエンジニアのブログ
  • Javaクラスファイルの読み方

    The document discusses Functional Reactive Programming (FRP). It provides an overview of FRP, explaining that it is a programming paradigm for reactive programming using functional programming techniques. It contrasts the treatment of values and events in FRP compared to traditional programming by treating events as values that change over time. Examples are given showing how FRP reacts to changes

    Javaクラスファイルの読み方
  • 知らないなんてもったいない! 障害発生の原因を洗い出すOSSのJavaVM解析支援ツール「HeapStats」を使ってみよう

    避けるべき状況ですが、残念なことにこのようなことは珍しくありません。解析に必要な情報を漏らさず取得するためには、サービス開始前に入念な準備が必要ですが、現実にはそこまで時間をかけられない場合もあり、往々にして準備不足となる場合があるからです。 こういった不幸な状況を防ぐ手段の1つとして、稿では「HeapStats」というツールを利用した障害解析方法を紹介します。 HeapStatsとは 「HeapStats」は、NTT OSSセンタが開発を行い2013年にOSS(オープンソースソフトウェア)として公開したJavaVM障害解析支援ツールです。 Javaアプリケーションにおけるメモリ不足(OutOfMemoryError)やデッドロックといった障害を素早く解決することを目的として開発されました。特に、Javaヒープメモリ内の状態など、従来は高い負荷をかけて取得する必要があった情報を、低オーバ

    知らないなんてもったいない! 障害発生の原因を洗い出すOSSのJavaVM解析支援ツール「HeapStats」を使ってみよう
  • Efficient data transfer through zero copy

    IBM 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.

    Efficient data transfer through zero copy
  • CloudWatch のカスタムメトリクスで JVM の GC を監視する | はったりエンジニアの備忘録

    JVM 上で動くアプリケーションを運用するには GC に気を配る必要があります。 GC をうまくチューニングするためには、まずは現状を知ることが大切です。 GC の統計情報は jstat -gcutil で取得することができます。試しに Jenkins のプロセスを見てみます。 $ pid=`sudo jps | grep jenkins | awk '{ print $1 }'` $ sudo jstat -gcutil ${pid} S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 57.68 21.33 66.26 99.51 73 0.179 4 0.271 0.450 この統計情報を定期的に取得してビジュアライズすれば GC の傾向がつかめます。この AWS 全盛期に昔ながらの RRDtool は使いたくないので、今回は CloudWatch でビジュ

    CloudWatch のカスタムメトリクスで JVM の GC を監視する | はったりエンジニアの備忘録
  • Java クラスファイルの構成 その2 - Qiita

    型指定子 (type descriptor) 型指定子はクラスファイル上でフィールドやメソッドの型を表現するのに利用される文字列です。 型指定子は型消去されたあとのジェネリクスを含まない型情報を表現します。 よく勘違いしている人がいますが、ジェネリクスを含む型情報は別途 シグネチャ と呼ばれる属性としてクラスファイル上に残っています。 ただ、JVM はシグネチャを無視するため、実行時にはジェネリクスを含む型情報を取得できないのです。 プリミティブ型の型指定子 プリミティブ型の型指定子は各プリミティブ型に対応したアルファベット1文字です。 プリミティブ型とそれに対応する型指定子は以下の表の通りです。 long が L でないのは L がオブジェクト型の型指定子で利用されているためです。(たぶん) ではなぜオブジェクト型の型指定子に L を使ったのは聞かないで下さい。(class の L ?)

    Java クラスファイルの構成 その2 - Qiita
  • 「Javaの鉱脈」でJVMオプションの記事を書きました | さにあらず

    WEB+DB PRESS の Vol.82 に、かなり気合いの入った JVM オプションの記事を書いたので、是非読んで頂きたい。 2014/8/23 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.82@Gihyo Digital Publishing今回の記事における対象読者について#今回の記事は、ターゲットとして Java に余り時間をコミットしていないけども便利なので JVM 上で動くアプリケーションをウッカリ運用している人をイメージしながら書きました。 例えば、OSS ものだと Hadoop や ZooKeeper、Lucene や Solr、商用製品だと Stash とか JIRA とか confluence とかそういうものですね。 僕の観測範囲だと、PHP

    「Javaの鉱脈」でJVMオプションの記事を書きました | さにあらず