2009-07-09 4 views
2

IエラーがJVMエラーアップデート14のJava 6にアップデートした後

に似ている14

Java 6のアップデートで実行するように(多分一日に一回)サーバの一握りを更新した後、いくつかの奇妙なエラーが発生してきましたStragely十分

# 
# A fatal error has been detected by the Java Runtime Environment: 
# 
# java.lang.OutOfMemoryError: requested 1759920 bytes for Chunk::new. Out of swap space? 
# 
# Internal Error (allocation.cpp:215), pid=26706, tid=317545360 
# Error: Chunk::new 
# 
# JRE version: 6.0_14-b08 
# Java VM: Java HotSpot(TM) Server VM (14.0-b16 mixed mode linux-x86) 
# If you would like to submit a bug report, please visit: 
# http://java.sun.com/webapps/bugreport/crash.jsp 
# 

、現在のスレッドは、コンパイラ

0x088a0800 JavaThread "CompilerThread1" daemon [_thread_blocked, id=26716, stack(0x12c7f000,0x12d00000)] 
=>0x0889e400 JavaThread "CompilerThread0" daemon [_thread_in_native, id=26715, stack(0x12e55000,0x12ed6000)] 

であると十分なメモリよりも多くあります:

は、

ヒープ

PSYoungGen  total 256064K, used 93533K [0xa2cd0000, 0xb4290000, 0xb4290000) 
    eden space 228352K, 31% used [0xa2cd0000,0xa72d6308,0xb0bd0000) 
    from space 27712K, 78% used [0xb2780000,0xb3cd1150,0xb4290000) 
    to space 28032K, 0% used [0xb0bd0000,0xb0bd0000,0xb2730000) 
PSOldGen  total 2275584K, used 885858K [0x17e90000, 0xa2cd0000, 0xa2cd0000) 
    object space 2275584K, 38% used [0x17e90000,0x4dfa8bf8,0xa2cd0000) 
PSPermGen  total 32128K, used 27819K [0x13e90000, 0x15df0000, 0x17e90000) 
    object space 32128K, 86% used [0x13e90000,0x159bac50,0x15df0000) 

I知られているJVMがクラッシュし、デバッグするのは難しいですが、あなたのいずれかが同様の問題に遭遇した場合、私は好奇心が強い - とどのようにそれらを解決しました。

+0

解決方法は、以前のJavaバージョンに戻すことです。このエラー報告をSunに提出してください。 – akarnokd

+0

私はJVMのクラッシュレポートの経験が不十分です。数ヶ月後にパブリックバグデータベースにも登場しませんでした。これが私がここで尋ねる理由です。 –

+0

サンにこれを書かなかったと言っていますか? –

答えて

1

バグはJavaコードのバグではなく、むしろJitコンパイラの1つの問題です。ジットが起動すると、それは何かのためのメモリとしてのメモリの束をsnagします。このメモリはネイティブヒープから来ています。

、それは文句を言わない通常の規則に従って振る舞う「本物」のOutOfMemoryErrorのない残念ながら、本当に興味を持ってこのエラーがVM(先にC++コード) http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#aRIt9pqzOVI/src/share/vm/utilities/vmError.cpp&q=OutOfMemoryError%20Out%20of%20swap%20space&l=258で、ここからultimatly発するためには、など

それをキャッチ傾けます

ネイティブ(JNI/JNA)メソッドは、OSから直接メモリを割り当てることができます。 NIOはメモリを直接使用し、ホットスポットコンパイラなどを使用します。

このメモリはアプリケーションのネイティブヒープ(mallocや友人によって管理されるもの)の一部です。アプリケーションがネイティブヒープを使い果たしている可能性がありますボックス上の全体的なメモリ、ulimit設定などを見てください.JNI/JNAコードは、アプリケーションがネイティブコード用に持つ利用可能なメモリを使い果たすことができる場合は、これに多少の影響もあります。 NIOのDirectMappedBuffersを見てください。これらは、Javaヒープからメモリを奪うことができるためです。

Jitコンパイラのいずれかのバグにヒットした可能性がありますので、GCとJitの設定がこれに影響する可能性があることを考えると、かなり可能性がありますので、-clientを-serverまたは-serverに変更してみてください。 -client)を実行して、GCポリシーを変更することもできます(ただし、GCポリシーを変更してjitとのやりとりを変更し、Javaメモリの問題を修正しないでください)。

また、コマンドラインフラグ-Djava.compiler = NONEを使用してJitを完全にオフにすることもできますが、ネイティブコード生成が削除されるため、パフォーマンスが低下します。

それ以外では、hprofクラッシュファイルをどこかにホストすると、いくつかのアイデアを提供することができます。

+0

精巧な答えをありがとう。私は既にこの問題を回避するために、アプリケーション内のスレッド使用を制限しています。私の直感は、スタックのサイズがu3とu14の間でバンプされており、そのためにメモリ不足になっているということです。 –

+0

-Xssで問題があると思われる場合は、Javaスタックサイズを制限できます –

関連する問題