開発ツール(QEMU)への貢献(前半) 〜自作OSのいまと昔 [第3回] | さくらのナレッジ
これまでの記事では、自作OSとそれを取り巻く状況について触れてきましたが、今回と次回は少し視点を変えて、自作OS開発で使うツールのデバッグや、それを通した貢献(contribute)の話をしたいと思います。 自作OSに限らず何かを開発する際には、たいていの場合、他の誰かが作ったツールを利用することになります。たとえば、CコンパイラとしてのClangや、デバッグのためのエミュレータとしてのQEMU, CやC++の標準ライブラリとしてのNewlibやlibc++などを、私の自作OS liumOS では利用しています。これらのソフトウエアは、ソースコードが公開されており、インターネット上の誰もが開発に参加することが可能です。 これらの開発ツールは、世界中のたくさんのユーザーに利用されるうちに、バグが見つかったり機能追加のリクエストが来たりすることで、完成度が次第に高まってきます。しかし、多くの人
![開発ツール(QEMU)への貢献(前半) 〜自作OSのいまと昔 [第3回] | さくらのナレッジ](https://cdn-ak-scissors.b.st-hatena.com/image/square/8ebd29a74c89a12937872cd0c76541b18eac1ab8/height=288;version=1;width=512/https%3A%2F%2Fknowledge.sakura.ad.jp%2Fwp-content%2Fuploads%2F2019%2F07%2Fjisaku_os.png)
恐怖の JVM 大量メモリ消費！メモリリークの謎を追え！！ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
Java: 本番環境でのデバッグスキルを磨く - ワザノバ | wazanova
https://www.youtube.com/watch?v=7KS4L-mA_-c 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Takipi のFounderであるTalWeissのSan Francisco Java User Groupミートアップでの講演。本番環境で役に立つデバッグテクニックの紹介です。 1. スレッド名の活用 スレッド名はmutable（EJB除く）である。コードのコンテキストにあわせて、Thread.currentThread().setName(Context, TID, Params, Time,...);のようにすれば、トランザクションID、Serveletパラメータ、キューメッセージID、起動時間など、スタックトレースに役に立つ情報を表示できるようになる。 J
Javaトラブルに応じた初動対応のまとめ - n-agetsumaの日記
Javaトラブルでは『情報がなくて、再現もなかなかしません』といった状況に陥ることがある。このような状況を回避するために、以下の3つの代表的なトラブルを例に、アプリケーションサーバを再起動する前に何を取得すれば良いのかをまとめてみる。 アプリケーションから応答がない アプリケーションが遅い ヒープメモリが足りない(OutOfMemoryErrorの発生) アプリケーションから応答がない 取得する情報 スレッドダンプ データ取得方法 スレッドダンプとは、コマンド実行時点でのJavaスレッド実行状態を出力したものである。応答がない場合、何らかの要因によりどこかで処理が止まっていることが想定される。スレッドダンプは『どこで止まっているのか？』を切り分けるのに大切な情報である。 取得方法はJDKのバージョンによって色々ある。 kill -3 <pid> (少なくとも1.4.2にはある〜JDK7でも
バグの数は予測できるのか？ 発想は斬新だけど評判の悪い「池の中の魚」モデル
バグの数は予測できるのか？ 発想は斬新だけど評判の悪い「池の中の魚」モデル：山浦恒央の“くみこみ”な話（48） プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。今回は、エンジニアの基本姿勢から逸脱した、一種のトンデモ推定法である「キャプチャー・リキャプチャー・モデル（別名、ソフトウェア版『池の中の魚』モデル」を取り上げます。 コーディングが終わり、コンパイルエラーも消え、いざデバッグ工程に突入――。このとき、「プログラムの中に隠れているバグの総数を正確に推定できたらなぁ……」と考えたことはありませんか？ こう考えるのは何もプログラマーだけではありません。プロジェクトマネジャーも、プロジェト管理や品質制御の観点から、バグ総数を高精度で予測することを夢見ています。 というわけで、新シリーズでは、この「ソフトウェア中の残存バグ数の推定」をテーマに取り上げ、今回から数回に
Androidアプリのメモリリーク対策手法 | Bescottee
googleのAndroid開発者向け ブログに「Memory Analysis for Android Applications」という記事があったため、自分のために訳しました。参考になれば幸いです。本エントリを見るうえで、eclipse の基本的な使い方を理解している必要があります。 Androidアプリのメモリ解析手法 Dalvikランタイムは、ガベージコレクトしてくれるかもしれませんが、それはメモリ管理を行わなくてもよいというわけではありません。モバイル端末上でのメモリ利用状況は特に注意を払わなければなりません。本投稿では、開発するアプリのメモリ利用状況の把握を支援する Android SDK で提供しているメモリプロファイリングツール群のいくつかを紹介させて頂きます。 メモリ利用時の問題はいくつか明らかになっています。例えば、もしあなたのアプリがユーザの画面タッチ操作のたびにメモ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
