★お前らJavaはJNIで組もうぜ★

★お前らJavaはJNIで� ..

608:デフォルトの名無しさん
09/01/02 03:49:02
SSEなんですけど、DLLが完成してループでテストすると1500回以内だと問題なんですが、それ以上だとするとJVMが落ちます。
mingwでsseなんですが、builtin_addpsのところで落ちてるみたいで、さらに、alinged_mallocつかっても無理でした。
２－３日調べてみましたが解決法はないみたいなんで、面倒だしSIMDについてはIntelにはもう全く期待しないでGPUやOpenGLの方でやります。
せっかくfftとか画像処理で使おうと思ってたんですけど、だれかJNIでSSE使ってる人いないですか？

609:デフォルトの名無しさん
09/01/02 03:54:04
このコアダンプももう見飽きたｗ

# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x61e012bb, pid=1668, tid=1888
#
# Java VM: Java HotSpot(TM) Client VM (11.0-b15 mixed mode, sharing windows-x86)
# Problematic frame:
# C [sse.dll+0x12bb]

Current thread (0x002b7400): JavaThread "main" [_thread_in_native, id=1888, stack(0x00900000,0x00950000)]

siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff

Registers:
EAX=0x00000000, EBX=0x26947e88, ECX=0x002b7a98, EDX=0x00000004
ESP=0x0094fbb8, EBP=0x0094fc00, ESI=0x0094fc2c, EDI=0x002b7400
EIP=0x61e012bb, EFLAGS=0x00010206

Top of Stack: (sp=0x0094fbb8)
0x0094fbb8: 002b7400 0094fc44 00000000 00000004
0x0094fbc8: 0094fbd8 47012a00 00a06a48 00a06fda
0x0094fbd8: c2040000 c2b00000 c2c60000 41b00000
0x0094fbe8: c7417200 c800f880 c8111580 47012a00
0x0094fbf8: 00989e07 0094fbfc 0094fc38 00a0926b
0x0094fc08: 002b7514 0094fc2c 0094fc24 00000000
0x0094fc18: 00000004 0094fc44 00000000 2298a768
0x0094fc28: 00988069 269483a8 2298a788 00000004

Instructions: (pc=0x61e012bb)
0x61e012ab: 45 08 89 04 24 8b 82 34 03 00 00 ff d0 83 ec 14
0x61e012bb: 0f 28 45 e8 0f 58 45 d8 0f 29 45 e8 8b 45 08 8b

610:デフォルトの名無しさん
09/01/03 13:09:32
sse命令を実行してるところ「だけ」コメントアウトしてみてはいかが
（メモリ確保などはそのままで）

それでも落ちるならsunに通報したほうがいいと思う

611:デフォルトの名無しさん
09/01/03 15:51:08
>>609
sse.dll+0x12bbで落ちてるって出てるんだから、そこ逆アセンブルして解析しろや。

612:デフォルトの名無しさん
09/01/03 23:37:43
sseつかっても結局メインメモリとのIOでアドバンテージも台無しになるから、xmmがfloat*4で８本程度だとあってもなくてもどうでもいいんだろうね。
一応cの方でベンチとってみたけど、fpuとsseでは1.3-1.8倍速くなる程度の開き（movapsつかうsseに有利なやつ）しかなかったから、
特殊な用途でもなんでもないのに、この程度でバグが出るならほっとくかな。
みんなfpuユニットの方使っててjvmでsseユニットを使うって需要がないんだろうな。

>>611
普通の用途でテストしてるのにバグってる（落ちる）ようなものは、残念ですけど使うつもりはありません。
それに、逆アセンブルして解析してバグ取りするのは私の仕事じゃないしｗ

613:デフォルトの名無しさん
09/01/04 01:34:02
一気にボルテージが上がったな

614:デフォルトの名無しさん
09/01/04 12:21:45
自分の書いたテストプログラムがバグっているのに、それを他人のせいにするキチガイがいるスレはここですか？

615:デフォルトの名無しさん
09/01/04 14:46:27
ソースコードを晒してくれればいじりようがあるんだが
今のままだと彼の妄言と区別しようがない

616:デフォルトの名無しさん
09/01/04 17:36:25
mingwでsseなんでだいぶ資料が少ないからついてこれる人がいるか心配なんですけどｗ
java側でループのテストして１－１５００回のループは通るのですがそれ以降はJVMが落ちて、この[1]から[2]の間でバイオレンスらしいです。
それとjfloat a[4]としてますが、型の宣言方法はいろいろあってそれぞれ試してみたんですけど、どうもbuiltin loadups, addpsの方が問題みたいでした。
addss のスカラー版はループテストは完了していて問題ないです。
まだ敷居が高いですけど、もしsseが使えてライブラリ化できるとjavaで画象処理とかエンコとかストリーム・ライブとかが少しは早くなるんじゃないでしょうか。

JNIEXPORT void JNICALL xxx_Lsse_add_1ps
(JNIEnv *env, jclass clj, jfloatArray dstj, jint ix1, jint cnt, jfloatArray srcj, jint ix2)
{

typedef jfloat v4sf __attribute__ ((vector_size(16))) __attribute__((aligned(16)));

jfloat adst[4],asrc[4];
v4sf d1,s1;

if (cnt<0 || cnt>=5) return;

(*env)->GetFloatArrayRegion(env, dstj, ix1, cnt, adst);
(*env)->GetFloatArrayRegion(env, srcj, ix2, cnt, asrc);

printf(" [1]s%d", global_loop++);
d1=__builtin_ia32_loadups (adst);
s1=__builtin_ia32_loadups (asrc);

printf(" [2]");
d1=__builtin_ia32_addps (d1,s1);
__builtin_ia32_storeups (adst,d1);

printf(" [3]");
(*env)->SetFloatArrayRegion(env, dstj, ix1, cnt, adst);
}

617:デフォルトの名無しさん
09/01/04 18:37:35
関数の仕様が分からないのは置いておくとして、
cntの値として0～3限定でなく、4がおkというのが気持ち悪くね？
(*env)->GetFloatArrayRegion(～)の時点でスタック壊れるだろ。caller側がたまたまcnt >= 0 && cnt < 4を保証してたら問題は顕在化しないだろうが。

話題としては逸れるが、このfloat4つ単位でJNI呼び出しちゃうという仕様はコスト掛けすぎ。pure Javaで書いたほうが１０倍速いと予想する。

618:デフォルトの名無しさん
09/01/04 18:55:22
Java側のコードも頼む

619:デフォルトの名無しさん
09/01/04 18:58:28
やっぱりついて来れる奴はいないか。
ま、せいぜいWebで資料（英語も）あさりでもしてバグ探してみてよ。

620:デフォルトの名無しさん
09/01/04 19:02:47
>>617
おまえの方が頭バグってんじゃねーの？ｗ

621:デフォルトの名無しさん
09/01/04 22:33:37
負荷試験のコードに向かって「コスト掛けすぎ」とか、なんという言いがかり。

622:デフォルトの名無しさん
09/01/04 23:37:49
なんの負荷はかってんのか、という問題では

623:デフォルトの名無しさん
09/01/04 23:51:05
1500の原因が呼び出し側にある気がするが
呼び出し側のコードがないので
今のままだと彼の妄言と区別しようがない

624:デフォルトの名無しさん
09/01/05 00:07:22
繰り返し呼ぶとJITコンパイラが動くんだけど、その回数がclient vmだと1500回だってさ。

-XX:CompileThreshold

URLﾘﾝｸ(java.sun.com)

1000回とかにして落ちる回数が変わったらこれかもな。

今回の件にどう絡んでるかわからん。
native method自体はJITコンパイル対象外だし。
スタックポインタの16bytes alignがズレてる可能性はあるかな。

adstやasrcのアドレスをprintfしてみるといいかも。

ま、>>616 にこれが理解できればの話だけど・・・

625:デフォルトの名無しさん
09/01/05 00:49:38
追加

使ってるgcc(mingwってgccだよね)のバージョンは？
こんなんあったぞ
URLﾘﾝｸ(gcc.gnu.org)

>>609 の落ちた場所のコードってmovapsじゃなくてmovupsじゃないか？
んでアドレスが16bytes alignされてない気がする
URLﾘﾝｸ(ds9a.nl)
を"0f 28 45 e8"で検索すると例がある

＞mingwでsseなんでだいぶ資料が少ないからついてこれる人がいるか心配なんですけどｗ

この程度でパニクってるお前の低脳さが心配だよｗ
レベル低過ぎｗ

626:デフォルトの名無しさん
09/01/05 01:13:27
デバッグご苦労。

627:デフォルトの名無しさん
09/01/05 01:50:17
素直に馬鹿はJNIなんて触るなっていっておけばいい物を・・・やさしいな

628:デフォルトの名無しさん
09/01/05 01:55:00
>>624
gcc (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.

gcc のそれは最適化すると勝手にアドレス替えちゃうって言うのじゃなかったか（特にスタックにある位置とasm("")のときも）。
スタックの話が出ると思ってたけど、ヒープ・メモリalligned_malloc(16, sizeof (jfloat)*4)でも
1500回目で落ちるからあまり関係ない感じはする。（１５００回以内は正常復帰であることが説明できない）。
そうするとjvm.dllの仕様なのかもな。1500を増やしても解決できるわけではないし、server vmにするわけでもないしなぁ。

それとJava側のコードとか普通に想像できるのしか使ってない。
何ていうか、普通に使うこの程度の用途でこんなバクが出てるんじゃ、Cやコンパイラ仕様に精通してないと全く刃が立たないし、
そもそもJavaから入った奴なんかチンプンカンプンでsimdなんかやる気なくなるだろうｗところで、他の人は同じバグでないの？

long nowtime;

float[] fa={1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,}, fb=new float[fa.length];

nowtime=System.currentTimeMillis();
for (int k=count; k-->0;){
ベクタライズ計算のあれ♪(fa,0,4,fb,0);
}
nowtime=System.currentTimeMillis()-nowtime;

629:デフォルトの名無しさん
09/01/05 02:08:24
未だに>>617みたいな分かてないトウシロもいるから書いておくけど、
JNIは「使うとアプリが速くなる」とか「速くしたいから」JNI使うとか言う代物ではないよ。

SUNの英語サイトでもさんざん書いてあるんだけど、Java/jvmだけでは実現できない機能への「アクセス」が目的で
アプリの速度とか機能の向上が目的なAPIではないよ。
例えばwin32apiとかsse,gpuとかのネイティブ機能を使うには唯一JNIを使うしかないってこと。
dot netだとこのへんもdot net frameworkに組み込んでunsafeとかで実現してるけど（winだけ）、j
vmは同じことをJNIのAPIで実現してる。

それからasmとかじゃないただのネイティブ・アクセスならこっちの方でライブラリ・パッケージ化されてるから、少しは敷居が低くなった。
たぶんwin32apiとか使う人はこれで事足りるんじゃないか？
URLﾘﾝｸ(en.wikipedia.org)

630:デフォルトの名無しさん
09/01/05 02:24:48
つまりjvm.dllの仕様とかgccのビルトイン関数の仕様が原因だと、ユーザレベルではどうしようもできないから解決法はない。
それに、この程度の利用方法でバグってるならSIMDは需要すらないってことだとから、人柱になるつもりもないな。
asmを直接使ってasmに神経使うつもりもないし。
C関数_mm_add_psのほうも使ってみるけど、もうIntelのSSEには期待してないからどうでもいいけど。

631:デフォルトの名無しさん
09/01/05 03:05:22
はあ・・・

オプションを1000にしたら落ちるまでの回数も1000になりましたか？

低脳君はこれだから・・・

632:デフォルトの名無しさん
09/01/05 03:10:27
>>627
こういう性分でな。

ま、低脳君のためにやってるわけではないので。
誰か（低脳君を除く）のお役に立てれば幸い。

633:デフォルトの名無しさん
09/01/05 06:41:26
JNIを呼ぶメソッドをHotSpotコンパイラの対象外に設定すればいいだけの話。

634:デフォルトの名無しさん
09/01/05 09:37:02
JNIはもともとHotSpot対象外だよ。何いってのこのオッサン

635:デフォルトの名無しさん
09/01/05 10:03:47
>>633
HotSpotですけど、インタプリタモードで全体のon/offは出来るけどピンポイントでメソッド単位では出来ないでしょ。
それともjava/javacでそういうオプションがあるんですか？
JNI FAQとかhotspot optionsを眺めてみたんですけど、そういうのはないみたいですよ。

一応 -serverでは大丈夫みたいなんで、たぶんhotなコードでHotSpotが効いてるのか、もしくは
FAQにもあったんだんですけどSSE使ってる最中のGC起動でどうとか言うバグ（GCがらみ）と思います。
つまりgccや私のコードでなくjvmのバグってことです。

636:デフォルトの名無しさん
09/01/05 11:59:45
つ.hotspot_compilerファイル
URLﾘﾝｸ(java.sun.com)

>>634
お前みたいな低脳見てるとイライラするわ。一生ロムってろ。

637:デフォルトの名無しさん
09/01/05 12:39:02
おいおい、それ
Note - The .hotspot_compiler file is an unsupported interface. It is documented here solely
for the purposes of troubleshooting and finding a temporary workaround.

とか書いてあるけど、中の人向けでやばいんじゃないの？
ていうかこれ、-XXオプションよりもSUNネイティブじゃんｗ
もしMSだったらそんな文書はます存在（公表）しないんじゃないのかと思う。「MS仕様です！」とかの域ｗｗ

638:デフォルトの名無しさん
09/01/05 13:02:43
RIAにC並みの性能をもたらす次世代のMozilla JavaScriptエンジン
URLﾘﾝｸ(www.infoq.com)

hotspot調べてたらこんな記事があったけどjvmではどうですか？
ざっと読んだところこの手法は、メソッドじゃなくてブロック単位でアスペクト切り替えみたいだけど、たぶん次世代な感じです。

それと .hotspot_compiler 使ってループテストは無事完了しました。
しかしこれではあまりにコアすぎるので他の方法でメソッド単位・クラス単位でJITコンパイル無効とかないですか？

よく考えると、JITコンパイルされようがなんだろうが、コードにバグがあるわけじゃなくてJVMの機構の問題なんで、
このような一時しのぎに頼らざる得ないのはおかしな話ですよね。awt.Canvas::paintとかどうしてるんでしょうか。

native funcやnative asmのret address がgcとかのデータ領域配置換えとかJITネイティブコンパイルによってコードのアドレスが変わって、ret先がずれてるってことなのかなと思う。
もうこのあたりはコアすぎて専門家か職人じゃなきゃ無理でしょ。

639:デフォルトの名無しさん
09/01/05 13:07:16
よってコード領域のアドレス

640:デフォルトの名無しさん
09/01/05 23:02:17
>>625
movupsならalignされてなくても問題ないのでは？

落ちた部分の
0x61e012bb: 0f 28 45 e8 0f 58 45 d8 0f 29 45 e8 8b 45 08 8b
を逆汗すると
MOVAPS XMM0,DQWORD PTR [EBP-18h]
ADDPS XMM0,DQWORD PTR [EBP-28h]
MOVAPS DQWORD PTR [EBP-18h],XMM0

EBPの値は>>609より、0x0094fc00なので、EBP-18h=0x0094fbe8。
ま、どう見ても16byte alignされてないな。
おしまい。

641:デフォルトの名無しさん
09/01/06 06:31:38
>>640
＞movupsならalignされてなくても問題ないのでは？

といってみたり、

＞ま、どう見ても16byte alignされてないな。

といってみたり、何をいいたいのかどうも良く分からないんだが。

もしかして、「俺ってアセンぶりぶりだぜ！！」ってこと？

642:デフォルトの名無しさん
09/01/08 21:55:10
バカホイホイスレ化してきました。

643:デフォルトの名無しさん
09/01/09 19:25:03
ここだけじゃなくてJava系スレは軒並みそうだけどな

644:611
09/01/16 01:06:01
>>609から、明らかにネイティブコードでアクセス違反起してるのに、JITコンパイル
が云々とか、もうね。

645:611
09/01/16 01:23:15
あ、悪い多分JITコンパイル関係あるわ。
JITコンパイルされて、呼び出し(Java)側のスタックフレームのサイズが変わったんだろ。
んで、インタプリタ実行中はたまたま>>640の言う、EBP-18hが16byteアラインになるEBP(SP)だったってことな。

つまり、>>616のローカル変数(jfloatかv4sf...SSEは素人なんて、どっちかわからん）を、16byteアライン
させれば直るだろ。
Cってアラインを強制する修飾子あるのかな？あるならそれ使って、
ないなら苦肉の策として、16byteのローカル変数突っ込めば、強制アラインされるから、多分直る。

jdouble aaaa; // ←追加
jfloat adst[4],asrc[4];
v4sf d1,s1;

あと利口なコンパイラだと、aaaaの使用点がないと、最適化で消しちゃうから適当な
仕様点作るとか。

646:デフォルトの名無しさん
09/01/23 20:45:33
C++(MFC)で作ったGUIプログラムをEcilpseのプラグインに移植しようとしています。
GUIだけをEclipseで作って、GUI以外は元のプログラムをそのまま使いたいのですが、
プラグインから元のプログラムをJNIで呼ぶのと、ソケット通信で呼ぶのでは
どちらが実装しやすいでしょうか？

647:デフォルトの名無しさん
09/01/23 21:49:29
ソケット通信部分が既に実装済みならソケット通信。
そうでなければ大して手間は変わらんと思う。

648:デフォルトの名無しさん
09/03/14 03:56:14
>>601
648ｹﾞｯﾄｵｫｵｵｫ!!!!!
　　∧∧
　 (^ω^)
　ｃu＿uっ　ﾊﾞｲｰﾝ
　　彡
　／￣￣＼
　|￣１￣|
　|￣２￣|
￣￣￣￣￣￣

649:デフォルトの名無しさん
09/04/07 02:00:47
久しぶりに来たがまだあったのか。息の長ぇスレだな。

650:デフォルトの名無しさん
09/04/07 10:05:03
ある大企業の久しぶりの仕事が
JNI使ったシステムの手直しだった。
全部Javaにすればいいのに。

651:デフォルトの名無しさん
09/04/07 10:50:08
COBOL 使ってたりするとそうも行かんだろう。最後丸めで金額計算とか
やってると精度保証のテストだけでエラい事になるぞ。

652:デフォルトの名無しさん
09/04/07 11:03:56
なぜわかるｗ
今動いている奴の方が信頼性高いしな。

653:デフォルトの名無しさん
09/04/07 13:35:54
動いてるプログラムと、いまから作るプログラムでは、圧倒的に動いてるプログラムのほうが信頼性高いな。

654:デフォルトの名無しさん
09/04/08 00:53:40
丸ごとシステム入れ替える予算も出ない状況だしな。
JNIで既存システムのライブラリ使って徐々に移行していくしかない。

655:デフォルトの名無しさん
09/04/14 21:20:40
とりあえず JNI で他言語呼ぶにしてもアクセス違反に巻き込まれて Java の
プロセスまで落ちては困るので RMI くらいは噛ませるよう設計している。
あるいはコマンド起動にしてしまうか。

C/C++ も全然平気が売りな SE としてはとにかく JNI は回避されるので
寂しい限りです。

656:デフォルトの名無しさん
09/04/14 23:36:39
RPC経由でもCORBAエラー出まくるだけだと思う。

657:デフォルトの名無しさん
09/04/14 23:57:23
縮退運用やフェールセーフ措置がとれるのでよっぽどマシです。

658:デフォルトの名無しさん
09/04/15 15:41:06
ちゃんと動いてればね。
CORBAエラー出まくって鯖再起動させられる事多いよ。

659:デフォルトの名無しさん
09/04/15 16:24:19
ローカルの Java プロセス間で通信させる程度に IIOP なんか使わないよ。
JNI 使ってる部分を別プロセスに分離できれば良いだけなんだから。
新たにアプリケーションサーバ立てるような大げさな構成考えてない?

660:デフォルトの名無しさん
09/04/15 17:51:57
うちの場合はハードウェア対応とパフォーマンスのためにJNIだから、あんまり関係ないなぁ。

661:デフォルトの名無しさん
09/05/15 08:08:30
>>648
　　ｻﾃﾄ
　 ∧∧
　(･ω･ )
　_| ⊃／(＿＿
／ヽ-(＿＿_／
￣￣￣￣￣￣

662:デフォルトの名無しさん
09/09/21 11:06:08
JNIは何をimportすればいいの？

663:デフォルトの名無しさん
09/09/21 12:23:38
おまえはimportが何なのかわかっていない
importは完全修飾クラス名を書くのが面倒なときにパッケージ名を省略するためのものであって
クラス名をすべて完全修飾で書くのならimport無しでもJavaのすべての機能を使える

664:デフォルトの名無しさん
09/09/21 12:45:15
インポートしても長いのに、まだ長くしようというのか。
嫌いじゃないが。
パス通して相対パスを使うよりも、常に絶対パス使えってことだろうけど。

665:デフォルトの名無しさん
09/09/21 13:16:13
どうせ書くのは宣言だけで、実際使う時は変数名になってるしね

オレはjava.ioとか付いてた方が意味がわかりやすいので、全部書いてるよ
書いてるというか、オートコンプリート機能で一覧から選んでるだけだけど

666:デフォルトの名無しさん
09/09/21 14:10:59
うわぁ…
Java利用者が減ったな

667:デフォルトの名無しさん
09/09/22 18:45:21
JNI使うような場面が減ったんだろう
まあいいことだ