postscriptErrata Revised January 27, 2004 For Postscript Language Reference, Third Edition, and for PostScript Language Reference Supplement for Version 3010 and 3011
調査の難しい「OutOfMemoryError」事例、5選
メモリ不足の問題の切り分け方の基本 まずは、メモリ不足がJavaヒープとCヒープのどちらで発生したかを切り分けておこう。 Javaヒープ OutOfMemoryErrorがスローされ、JavaVMの実行が継続している場合には、Javaヒープが不足している可能性が高い。Javaヒープ不足かどうかを確定させるために、スローされたOutOfMemoryErrorのトレースを確認しよう。 java.lang.OutOfMemoryError: Java heap space <=======【*1】 at java.nio.CharBuffer.wrap(CharBuffer.java:350) <=======【*2】 at java.nio.CharBuffer.wrap(CharBuffer.java:373) at java.lang.StringCoding$StringDecoder.
JAVAヒープサイズ・GCチューニングのまとめ
システム開発に役立ちそうな情報を日々メモしています。世の中の開発現場が少しでも平和になることを祈ります。 ■ 前提条件 ----------------------------------------------- JVMは、Sun Java (JDK 1.5-1.6)を想定。 ■ 目標 ----------------------------------------------- ・マイナーGC、フル GCがそれぞれ頻発しないこと。 ・フル GCの実行時間が1秒未満であること。 ・マイナーGCの実行時間が0.1秒未満であること。 ・連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 ・理想的な状態は、上記に加えて、フル GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジ
Java VMのメモリ不足――原因切り分けから解決まで
Java VMのメモリ不足の問題は、解決までに時間を要する。だが適切な初期調査を行えば、ある程度まで原因を絞り込め、早期解決につながる。今回はメモリ不足問題の対応方法を、体系立てて解説する。 問題解決のポイント Java VMでメモリ不足が発生した時に重要となるポイントは、早期に発生個所の特定と原因の切り分けである。 Webシステムでメモリが不足すると、「java.lang.OutOfMemoryError」メッセージが出力される。このメッセージが出力された時、最初に行うことは、WebサーバやJava VMのログを確認することだ。これらのログから障害の痕跡を発見できると、障害内容からメモリ不足の原因を切り分けられる。しかし、使用しているJava VMによっては、障害の切り分けに必要な情報が得られない場合もある。その場合、GCログが障害解析の資料として役に立つ。 以降、Webシステムを例に、
サーバサイドJavaでのメモリ上限
Programming SHOT BARへようこそ。本日はVMの管理するメモリの話です。メモリリークによるOutOfMemoryの話ではありません。 VMが扱えるメモリの上限 一般的な32bitのJavaVMが管理できるメモリの上限は1.7G程度です。 JavaのVM自体はOSから見れば単一アプリケーションにすぎません。 Javaのアプリケーション内でのメモリ確保は、VMが確保したメモリが分配されているわけです。ですから、OS上からJavaVMが確保しているメモリを見てもVM内でどれだけのメモリが利用されているかはわかりません。 これはわりと嵌る人が多いように思います。少なくとも過去にBBSで2度以上見た覚えがあります。 Javaでもメモリ使用量を観測しようとした場合、WindowsのタスクマネージャでJavaVMが使用しているメモリを見てもあまり意味がありません。これはVMが確保している
64bit版Javaの実力 - torutkのブログ
Windows Vista 64bit版上で、JDK 1.6 x86/x64版をインストールして、64bit版の能力を探ってみました。 実験環境の構成 CPU AMD Athlon 64 x2 4200+ メモリ 2GB OS Windows Vista Ultimate 64bit JVM Sun JDK 1.6 U2(1.6.0_02) 64bit長のデータアクセス 2つのスレッドを並列実行させ（デュアルコアPC）、スレッド間で共有する64bitプリミティブ型（long）を排他制御なしに1つのスレッドがwriteしもう1つのスレッドがreadし、意図しない値（32bitで分断）が観測されるか否かを実験しました。writeスレッドは、共有変数に次の2つの値を交互に書き込み続けます。 0xAAAAAAAAAAAAAAAA 0x5555555555555555 readスレッドは、共有変数か
19.1 OutOfMemoryError発生時の対処
Javaアプリケーション実行時にOutOfMemoryErrorが発生した場合、次の原因が考えられます。 Javaで使用するメモリ(ヒープ域)不足 通常、OutOfMemoryErrorは、このケースで発生します。 Javaの使用するメモリは大別すると次の3つに分かれます。 New世代領域 Old世代領域 Permanent世代領域 仮想メモリ不足 ヒープ域以外にシステムの仮想メモリが不足した場合にもOutOfMemoryErrorが発生します。このような場合、仮想メモリを増やすように変更をお願いします。 なお、仮想メモリが不足してスレッドが生成できない場合、OutOfMemoryErrorに次の情報が付加されます。 java.lang.OutOfMemoryError: unable to create new native thread Javaプロセスのユーザ空間不足 ヒープ域やシス
Unicode
Unicode のブロック名称と Unicode Code Charts へのリンクです。 右欄に、JIS X 0221-1 に掲載されている日本語名称を掲げます。 この欄の (4.1.0) は Unicode 4.1.0 で追加されたブロックであることを示します。 リンク欄に(注)があるブロックは、ファイルサイズが大きいためコピーしたファイルを参照しています(2005-9-25)。 fromtoブロックの名称 および Unicode Code Charts へのリンクX 0221-1 付属書Ａ A.2 より \u0000\u007F
ステップ数よりスペック数 - Sacrificed & Exploited
ソフトウェアの規模は、ハードウェアの規模がそうであるように生産量ではなくスペックである。実現方式が違えば生産量の定義が変わる。そんなバカなことはない。プレス加工だろうが、鋳造だろうが、生産量の定義が変わるはずがない。ソフトウェアの規模を生産量扱いするというのは、加工方法が変われば生産量の定義が変わるというようなもの。これでは、異なる加工方法間での生産性の比較ができず、生産性の大幅な改善は期待できない。ソフトウェア開発の生産性が向上しないのも、生産量の定義が間違っていることによるものが大きい。 ソフトウェアにおける開発はハードウェアにおける設計 - 酔狂人の異説 に触発されてこのエントリを書きました。 はじめに これまで、私はウォーターフォール型の開発プロセスを使った現場でプログラマをしてきました。 しかし、いくら設計書をちゃんと作っても、バグが無くなったり、 進捗管理を厳しくやっても、スケ
ウェブリブログ：サービスは終了しました。
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
フランス語とマニュアル (英仏翻訳の老舗 - 翻訳会社ジェスコ）
ヨー ロッパ言語のマニュアルを扱う企業、或いは翻訳会社の方も、英語以外の言語ではちょっとした訂正も大変な作業だと痛感されていると思います。フランス語の 場合、単語をひとつ変更するだけでも、英語のように簡単にはいきません。名詞をひとつ変えるだけでも、男性、女性を考えねばならず、それに伴い代名詞、形 容詞、過去分詞の単複、性の一致を考えなければなりません。フランス語の知識もなく手を出そうものなら、後でひどい目にあうことになります。 ---> 例は、こちら。 と はいえ、単語ひとつのために海外に変更を依頼したり、フリーランスのフランス人に尋ねたりしていては仕事がはかどらない場合が多いと思います。ましてや、 夜中や土、日だと更にその歯がゆさを実感することになります。最低限度のことは、自分でするしかありません。また、社内にフランス語の分かる社員がいない 翻訳会社或いはメーカーの方も、マニュアルの中
Technical Note TN2147:Mac OS XにおけるJNI開発
JNI (Java Native Interface)は、JavaコードとCの派生言語(C、C++、Objective-C)で書かれたコードを統合するための標準メカニズムです。これを使用して、データにアクセスしたり、ネイティブな要素をJavaユーザインターフェイスに組み込んだり、ネイティブなアプリケーションからJava仮想マシン(JVM)を作成したりすることができます。このテクニカルノートでは、Mac OS XでのJNIプログラミング特有の手法や問題を、必須事項（および禁止事項）の明示的な例を挙げながら説明します。すでにMac OS X上でJNIを使用している場合、またはMac OS X上のJava以外のフレームワークの1つとのインターフェイスが必要なアプリケーションを、Java 1.4以降で作成している場合は、このテクニカルノートをお読みください。また、アプリケーションからJavaのライ
JNIコーディングメモ(Hishidama's Java native interface coding Memo)
JNIのC言語/C++側のコーディング C言語とC++の違い コーディング例 JNI関数の概要 プリミティブ型・参照型（JavaオブジェクトのC/C++での扱い） String型 [/2006-11-09] 配列型 クラスの取得・インスタンス生成 [/2008-02-02] オブジェクトのメソッド呼び出し [/2008-02-07] オブジェクトのフィールド操作 ローカル参照の終了 [2006-11-09] 例外処理 [/2007-10-13] jni.hの中でC言語/C++で使える構造体 （クラス）が定義されているが、 コンパイラーがC言語の場合とC++の場合では定義のされ方が異なり、使い方も少し異なる。 JniJikken.c： JniJikken.cpp： #include "JniJikken.h" JNIEXPORT jbyteArray JNICALL Java_JniJikk
Checkstyleの「Got an exception - expecting xxx, found EOF」の解決方法 - 現場のためのソフトウェア開発プロセス - たかのり日記
CheckstyleのEclipseプラグインを使っていると、以下のようなエラーが大量に出力される場合があります。 Got an exception - expecting xxx, found EOF このエラーは、OSデフォルトのエンコードとソースコードのエンコードが一致しないために、Checkstyleがエンコードを正しく認識できていないために発生します。 エラーが出ないようにするには、Checkstyleの設定画面を開き、「Other」→「TreeWalker」の設定で、「charset」項目でエンコードを指定することで解決できます。 ルールファイル（XML）を直接編集する場合は、以下のように指定します。 <module name="Checker"> <module name="TreeWalker"> <property name="charset" value="UTF-8"
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostScriptリンク集
IBM Developer
7.4.2 java.lang.OutOfMemoryErrorがスローされた場合
JNI実験ページ
Shibboleth Authentication Request
JavaMail API Reference Implementation — Project Kenai