2012年02月08日

[java]sun.reflect.GeneratedSerializationConstructorAccessor の正体

sun.reflect.Generatedほげほげ などの解説

-これは何?



 reflectionを行うときの ByteCode Accessor


-は?



 アクセッサーには2種類あり、JNI AccessorとByteCode Accessor
 ご存知のようにJNI操作はコストが高いので、頻繁に呼び出されるとJNIからByteCodeへ昇格される
 そうすることで、reflectの動作を高速化させている。
 これが導入されたのはJRE1.4x以降



-このクラスをロードしたとか消したとかでまくるんだが、ぉぃい



reflectAPIの呼び出し単位で作成されてしまうので、フレームワークなんかを
使っているともう吐き気するぐらい作成される。
ClassオブジェクトなのでJVMのバージョンによってはHeapの中では厄介ものである
(フラグメント要因になる)。
だが安心してほしい。弱参照状態で作成され、参照は親のClassLoaderだけなので、
「使用中」でなければ破棄できる。
破棄されたものは、再びJNI Accessorからの出直しになる。



-それって、パフォーマンス元に戻るんじゃね?意味なくない?


パレートの法則。80:20の法則。

 GC対象になるようなAccessor = 未使用 =20%部分じゃない =パフォーマンスに影響を与えない

 パフォーマンスチューニングにおける大前提である。



-制御したいんだが



  -D sun.reflect.noInflation = false (default value is false)
  -D sun.reflect.inflationThreshold = 15 (default value is 15)

  noInfration =true は進化をやめよ、となり、デフォルトでbyteCodeAccessorが作成される
  よって、マッハになるかもしれないがsun.reflect.Generatedほげほげの数は増える

  inflationThreshold は進化までの回数。デフォルトでは15回呼ばれるとHot判定になりbyteCodeAccessorが作成される

  普通はこんなコアな設定はさわらんでよろしい。
  その前に直すべき箇所があるはずである。



参考リンク
https://www.ibm.com/developerworks/mydeveloperworks/blogs/738b7897-cd38-4f24-9f05-48dd69116837/entry/reflection_a_memory_viewpoint3?lang=ja
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html
http://stackoverflow.com/questions/2971019/how-to-avoid-generatedserializationconstructoraccessor-problems
posted by koteitan at 11:23| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック