- アプレットとスタンドアロンJavaプロセスのXmxの違い

Question

クライアントが持つデータの数に応じて、より多くの、またはより少ないメモリを必要とするアプレットがあります。

通常、Java 1.6の最新バージョンを使用することをお勧めしますが、実際にはJava 1.5+をサポートしているため、アプレットには「メモリ不足」に関する警告とダイアログボックスが表示され、想い出。

しかし、私は、アプレットとスタンドアロンプ​​ロセスで-Xmxの動作が異なっており、実際にアプレットに十分なメモリがあるかどうかを判断できないことに本当に驚きました。ここで

は、それがどのように行われるかである。

• アプレットは、次の引数を受け取る：
  • のparamの名前= "java_arguments" 値= " - Xmx153mは、"（もちろんこれは、Java 1.6のアップデートで動作します10、それ以外の場合は、Java 1.5およびJava 1.6で64M前更新10を取得します）実行時に
  • のparamの名前= "required.memory" 値= "153"
• 、我々は、私たちは143589376取得アプレットで153Mの限界とRuntime.getRuntime（）。maxMemory（）
• でrequired.memoryを比較するが、スタンドアロンアプリケーションでは、我々は155516928
• 153×1000×1000 =1.53億を取得（私は1Kのために1024を使用していません）、それは間違いなく143589376です。

私は、正しい値 - 0.9？この制限をどのように計算し、スタンドアロンアプリケーションとアプレットで異なるのはなぜですか？

Answer 1

Javaメモリー上の時間。

まず、Javaでメモリが不足している（実際にはOutOfMemoryErrorを取得しています）のは、動作しているGCの特性の影響を受けます。

名前の意味とは異なり、実際にメモリが足りなくてもOutOfMemoryErrorを得ることができます。ランタイムがその支出にGC'ing（source、その中に埋もれている）の過度な量を決めるときにも投げられます。

さらに、メモリの特定の種類のが不足してOutOfMemoryErrorが発生することがあります。 Java GCは世代別コレクターであり、世代のうちの1つを使い果たした場合（「テニュア」と言いたいが、間違っている可能性がある）、あなたは事実上メモリ不足になることを覚えておいてください。つまり、OSビューからヒープスペースを残しておくことはできますが、Javaヒープ上には何も配置できません。

最後に、ヒープスペースを少し食いつぶす可能性のあるGCに関連する実際のオーバーヘッドがあります。

あなたのケースで何が起こっされる可能性が高い何

---

、次のようにいくつかの変異体である：あなたのコードはスタンドアローンとアプレットコンテキストの両方で動作し、各コンテキストが異なるセキュリティマネージャと異なる起動時の動作を持っています。これは、（永続的な世代にノックされる）異なるクラスのセットが、異なる依存関係で関与していることを意味します。私は、アプレットの "スタック"は、より厳しい制約が与えられていることを考えると、より厚く、おそらくmaxMemory（）の違いの大半を占めていると思います。要するに、利用可能なメモリの違いは、Javaランタイムが独自の操作用に予約したメモリが多少変更されたためです。これは、GC関連、セキュリティポリシー関連、またはアプレット環境用に読み込まれたクラスとスタンドアローン環境用にロードされたクラスだけである可能性があります。 Runtime.maxMemory（）は、何を返すかを決定する際に、上記の「メモリー不足」条件のいずれかを考慮に入れることができます。したがって、0.9の値はおそらく実装上の副作用であり、将来変更する可能性があります。

Answer 2

ケビンは、アプレットがデスクトップアプリケーションと比べてどのように動作するかの違いがありますが、私には大きな違いがあります。あなたが「アプレット」スタックを「より重くしている」と言われた場合、私はアプレットがスタンドアロンではなく最大の最大メモリを取得することを期待していましたバージョン。

私は、アプレットとアプリケーションの間でいくつか測定しました。どちらも同じパラメータ（-Xmx128M）を受け取りました。どちらも同じJVMで実行されています - Java HotSpot（TM）64ビットサーバVMバージョン11.3-b02（初めてアプレットがクライアントJVMで動作していて、サーバーJVMが、両方がサーバJVMであるようだ）

もちろん現実異なるパラメータで受け取ったのJVMが、主要な何も（と思う）：

• アプレット：-D__jvm_launched = 426431678538 -Xbootclasspath/A ：/usr/jvm/64/jdk1.6.0_13/jre/lib/deploy.jar：/usr/jvm/64/jdk1.6.0_13/jre/lib/javaws.jar：/ usr/jvm/64/jdk1。 6.0_13/jre/lib/plugin.jar -Xmx128m
• スタンドアロン：-Xrun jdwp：transport = dt_socket、address = 127.0.0.1：54876、suspend = y、server = n -Xmx128M -Dfile.encoding = UTF-8

アプレット：メモリ= 119.314K

• ヒープ
  • PSエデンスペース：14,592K
  • PSの遺族スペース：14.528K
  • PS旧世代：87.424K
    • 合計：116.544K
• 非ヒープ
  • Memのプールコードキャッシュ：49.152K
  • MemのプールPSパーマゲン：86.016K
    • 合計：135。
  168K

デスクトップ：最大。メモリ= 129.302K

• ヒープ
  • PSエデンスペース：8.704K
  • PSの遺族スペース：3.008K
  • PS旧世代：116.544K
    • 合計：126.272K
• 非ヒープ
  • Memのプールコードキャッシュ：49.152K
  • MemのプールPSパーマゲン：65.536K
    • 合計：135.168K

それら2つのJVMの大きな違い

• PS Perm Genでは、アプレットがより大きなチャンクを持っています。アプレットがスタンドアロンバージョンと比較しておそらく追加のクラスをロードするので意味があります（この場合でも「Old Gen」はずっと小さくなります。
• エデン/サバイバー/オールドジェンの間で全く異なる比率のヒープメモリアプレットの旧世代は、スタンドアロンの旧世代の75％であり、私は、アプレットとして、またはデスクトップアプリケーションとしてアプリケーションを実行しているときに、何の違いもないはずなので、同じメモリモデルを（ほとんど）期待していれば大丈夫です。

私はmaxMemory比率を計算する方法がわからないだけでなく（実際には0.9は将来のJVMバージョンでは有効ではありませんでした）、私のアプリケーションはメモリ不足になる可能性がありますアプレットとして実行されます。安全のためにアプレットとして実行する場合、最大メモリーを〜10-15％増やす必要があります。

（同じマシン上の）異なるヒープ率と小さなヒープ（なぜなら、アプレットには追加のクラスが必要であることを考慮している）をまだ確信していません。

何らかの理由がありますか？私は今、面倒です。アプレットに最大限のメモリがあるかどうかを確認する必要があります。