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 | このブログの読者になる | 更新情報をチェックする

[java]備忘録2012 JDK1.4.2の(以下略


ダークマターによるGCの誘発について
http://www-01.ibm.com/support/docview.wss?uid=swg21214654

IBMJDKにおけるIC(Incremental Compaction)について
http://www.ibm.com/developerworks/ibm/library/i-incrcomp/

IBMJDKが巨大オブジェクトをどのように扱うのか(LOAの説明)
http://www-01.ibm.com/support/docview.wss?uid=swg21236509

その他GCの動きの説明
http://www.nminoru.jp/~nminoru/java/cms/concurrent_mark_sweep.html#45


ヒープ圧縮(shrink)について
http://www-01.ibm.com/support/docview.wss?uid=jpn1J1004853

IBMJDK1.4.2におけるComapction発生要因
http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/topic/com.ibm.java.doc.diagnostics.142/html/id1156.html?path=0_5_7_2_5#id1156

※Reason8 transient heap云々Compactionは zOSのみでAIX/Linux/Win では発生
しない

posted by koteitan at 11:12| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

[Java]備忘録2012 JDK1.4.2のこまごま

kCluster と pCluster の説明
http://www.ibm.com/developerworks/jp/lotus/library/dm-0802tessarek/index.html#AS_4
http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.142%2Fhtml%2Fpinnedclusters.html
http://www.atmarkit.co.jp/fjava/rensai4/websphere03/websphere03_4.html
http://www-01.ibm.com/support/docview.wss?uid=swg21196072

JDK1.5からはこのkCluster枯渇によるヒープフラグメンテーションは発生しない。

巨大なメモリ要求を確認するには、ALLOCATION_THRESHOLD変数を設定する
(1.3.1SR10?、1.4.2SR4?)
1.5、1.6は別の変数(-Xdumpの設定で行う)
設定すると、少し負荷が上がる。

http://www-01.ibm.com/support/docview.wss?uid=swg21236523
posted by koteitan at 11:10| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2012年02月07日

[DB2]こまごま

コマンド覚えられないのでメモしとく

ID列の値はinsert毎に更新されていってしまうので、追加しまくるとどんどん
連番がかけ離れてずれてくる。
そこで、loadとimportの間にID値を調整する。調整するのは以下のコマンド

ALTER TABLE テーブル名
ALTER COLUMN 自動生成するカラム名
RESTART WITH 設定したいID値


愚痴
 データの文字列に指数表記っぽい文字があったのを
 なんも考えずにExcelに貼ったら指数と解釈されて酷い目にあったこと
 
 なんも考えずにimportしたらデータ部に改行があり、ズレまくってエラい目にあったこと

気をつけるんやでヽ(`Д´)ノ
posted by koteitan at 11:22| Comment(0) | TrackBack(0) | DB2 | このブログの読者になる | 更新情報をチェックする

[DB2]カラムの拡大

昔だとexport-drop-create-loadやんね (´-ω-`)

ALTER TABLEの ALTER COLUMNでこちょこちょやれば出来てしまう。
こういう便利なのがあるから、テーブル設計がおざなりでもなんとかなってしまい、
結果品質の低下したアプリケーションと形骸化した設計書ができあがり、引き継いだ作業者が
混乱し、さらなるデスマー(以下略

本当は知らなくても問題無いように設計したいね。
でも真田イズムの如く、「こんなこともあろうかと」は大事。

db2 "ALTER TABLE HOGEMASTER ALTER COLUMN HOGENAME SET DATA TYPE VARCHAR(128)"



http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom.ibm.db2.luw.sql.ref.doc%2Fdoc%2Fr0000888.html
posted by koteitan at 11:17| Comment(0) | TrackBack(0) | DB2 | このブログの読者になる | 更新情報をチェックする

[DB2]ID列へのLoad

db2 ID列を含むものの自動生成させてLoadするには、該当の列にもダミーのデータ
を入れたCSVで。

$ db2 "import from hoge.csv of del modified by identityignore insert into
HOGEMASTER "

こんなん

ID列を無視して、実データで入れるとき(Load用)は

$ db2 "load from tab5.ixf of ixf modified by identityoverride REPLACE into
HOGEMASTER NONRECOVERABLE"

もちろん、そのあとには
$ db2 "set integrity for HOGEMASTER immediate checked"

して、整合性をとらないとだめ。
posted by koteitan at 11:09| Comment(0) | TrackBack(0) | DB2 | このブログの読者になる | 更新情報をチェックする