07/07/30 19:01:48
それは気にし過ぎ。
2GのファイルとかにMMXするの考えてみて
501:デフォルトの名無しさん
07/07/30 19:09:34
MMX使っても、メソッド呼び出し1回で 2Gのファイル処理しないとペイしないのか。
502:デフォルトの名無しさん
07/07/31 04:49:18
比べる土俵が違うんじゃないか。
例えばMMXはJavaにはない機能なんだが、JNI使用しないとつかえないわけで。
503:デフォルトの名無しさん
07/07/31 05:30:13
いみわからん
504:デフォルトの名無しさん
07/07/31 07:46:43
>>503 おまえは あほか
505:デフォルトの名無しさん
07/07/31 10:43:39
java vmのソースも公開されたことだし、jitコンパイラをハックして
mmx/sse等を使うようにしてみるのも楽しいかもね！
506:デフォルトの名無しさん
07/07/31 12:58:02
>>502
>>504
速く処理を終わらせることが目的なのか、MMXを使うことが目的なのか。
大多数の人にとってはMMXは手段であって目的ではない。
507:デフォルトの名無しさん
07/07/31 14:54:43
>>503 おまえ MMY つかったことないだろ
508:デフォルトの名無しさん
07/08/02 12:00:16
>>506 おまえ MMZ つかったことないだろ
509:デフォルトの名無しさん
07/08/02 19:16:27
JNIの呼び出し、戻しって遅いしね。つかえね～
510:デフォルトの名無しさん
07/08/02 19:50:22
MMWなら使った
511:デフォルトの名無しさん
07/08/02 21:05:37
なんと！
512:デフォルトの名無しさん
07/08/03 08:27:36
JNIのほうではmemcpy相当
Javaのほうではarraycopy相当
で1000万回やったけど、
native.dllのままで、8秒。
native.dllをcl /02 /GDで最適化して5秒。
arraycopy呼び出しは1秒。
JNIの関数呼び出し戻しって遅いよ。
どうにもならないだろうね。
513:デフォルトの名無しさん
07/08/03 09:14:16
関数呼び出し戻しの時間を測定するために、ちょっとDLL作って計ってみた。
public static native long callfunc(long q);
public static long callmeth(long q)
で、引数を何もしないで返すだけ。clは/Ot /GA
100 000 000（1億回）で、
3435 mill
290 mill
およそ10倍。呼び出し回数が異常に多いと、JNIは遅すぎ。
514:デフォルトの名無しさん
07/08/03 09:17:11
ああ、環境は、
windows 2000
jdk 1.6.0.1
cl vc++ 2005
515:デフォルトの名無しさん
07/08/03 11:40:12
JNIコールが遅いってのは、javaプログラマの常識。
呼び出しそのものが遅いってのもあるけど、JNI関数内がJVMからみて不透明なので、
最適化の阻害要因にもなる。
JNI使うのは、JVM経由ではサポートされないプラットフォーム固有のリソースを使うとか、
画像処理なり数値演算なり、CPUパワーに強く依存する処理を大きな単位でC/C++化したりする
ときぐらい。
516:デフォルトの名無しさん
07/08/03 12:55:49
でも呼び戻しが遅いから、その苦労は、相殺される。
517:デフォルトの名無しさん
07/08/03 12:58:40
>>500が言うみたいに、2Gとかのファイル処理じゃないと割に合わんね。
518:デフォルトの名無しさん
07/08/03 13:11:32
JVMでは、スクリプトばかりに日がさしているけど、
JNIが日の目を見るのはいつなのか・・
519:デフォルトの名無しさん
07/08/03 16:09:45
ＪＶＭ内に取り込めばいいだけの話だろ
オープンソースなんだし
520:デフォルトの名無しさん
07/08/03 16:13:36
JVM内に取り込むって、どーゆー事？
521:デフォルトの名無しさん
07/08/03 16:22:38
>>517
それだけJavaも進化したものだとつくづく思う
522:デフォルトの名無しさん
07/08/04 07:18:12
>>520
JNIなしでネイティブを呼び出す
523:デフォルトの名無しさん
07/08/04 09:43:46
しかし、関数呼び出しがこれほど遅いとはおもわなんだ。
1億回も呼び出すことはないかもしれんが、100万回ぐらいは普通にあるだろ。
in.read()を100万回だと、１Gのファイル処理になるから。
524:デフォルトの名無しさん
07/08/04 09:45:58
100万で1Mファイルだった。
525:デフォルトの名無しさん
07/08/04 12:01:59
>>522
GC管理外にオブジェクト持ち出すための準備はJNIでなくても必要になるだろうし、
JITコンパイラがネイティブコードとJavaのコードを混ぜて最適化ってのも期待できないから
仮にJNIなしでネイティブ呼び出ししても、呼び出しコストが高くなるのは変わらんと思うよ。
期待できるのはJNIって名前が変わる事ぐらいか。
526:デフォルトの名無しさん
07/08/04 12:03:27
んなこたない。
527:デフォルトの名無しさん
07/08/04 12:10:10
>>523-524
そゆこと。
FileInputStream で1バイト読み込みの read() 連発すると滅茶苦茶遅くなるしね。
528:デフォルトの名無しさん
07/08/04 14:06:31
>>527
チマチマやったとしても、実際問題、OSの方でバッファされてるんじゃないか？
529:デフォルトの名無しさん
07/08/04 14:09:29
いや、JNIの呼び出しコストの話
530:デフォルトの名無しさん
07/08/04 14:14:20
>>525
例外を Java側にスローする際の後始末とかもあるし。
531:デフォルトの名無しさん
07/08/04 14:49:16
>>529 そうだった。
532:デフォルトの名無しさん
07/08/04 14:51:07
といっても、実際問題では2Gのファイル読み込むわけではないし、
むちゃくちゃ遅いって事はないだろ。せいぜいjpegで1,2秒まち。
533:デフォルトの名無しさん
07/08/04 14:56:55
べつにJavaじゃ無くても、ファイル読み込みはネイティブでもそれぐらい時間かかるし。
534:デフォルトの名無しさん
07/08/04 15:03:09
ファイル読み込みが遅いって言ってるんじゃなくて、
JNIの呼び出し回数を増やすと遅くなるって話なんだが。
FileInputStream#read() で 1バイトずつ読み込むのと
FileInputStream#read(byte[]) で 1024バイトずつ読むのとを比べたら
後者の方が圧倒的に速い。
535:デフォルトの名無しさん
07/08/04 15:08:15
ああ、わかってる。
ファイル読み込み(IO)は、Javaのアプリじゃなくて、ネイティブのアプリでやっても、
（1M）は1秒ぐらいかかるから、体感では変わらないってことがいいたかっただけ。
JNIはIOでは仕方なく使うことになるけど、
それよりcodecとかzipとかawtで活躍するんだろうと思う。
536:デフォルトの名無しさん
07/08/04 15:20:24
動画用codecとかawtもハードの機能使ったりする可能性考えるとネイティブにせざるを得ないでしょ。
zipも、ブートストラップクラスローダの初期段階では java.util.zipがロードできてない段階で
zipファイルからclassファイルを読み込む必要を考えると、
ネイティブでzlib相当のライブラリを持って無いとダメっぽい。
537:デフォルトの名無しさん
07/08/04 15:26:41
JavaはCより速いから、IO以外の場所でnativeを使う理由はない。
538:デフォルトの名無しさん
07/08/04 15:28:11
よって全てのライブラリは100% pure javaで作成されるべき。
539:デフォルトの名無しさん
07/08/04 15:47:44
>>536
最近はDRMとかあるから、ハードの機能だけじゃないかもしれんな。
540:デフォルトの名無しさん
07/08/04 17:10:30
JNIはJavaより速いかどうかで使う代物ではないな。
Hack専用。高次元技能者専用。したがってシャア専用。
541:デフォルトの名無しさん
07/08/04 17:16:26
JNIなんて仕方なく使うもんだろ？泥臭さの極致。
バッドノウハウ
だな。
542:デフォルトの名無しさん
07/08/04 17:21:42
JAMの登場でそうも言ってられなくなるかもな。
jarやdllを埋め込めるようになるから、準標準VMのごとく
仕様を拡張してくる団体が現れても不思議じゃない。
543:デフォルトの名無しさん
07/08/04 22:47:28
>バッドノウハウ
どういう意味？
>JAMの登場でそうも言ってられなくなるかもな
JNIと関係ないと思うけど。
544:デフォルトの名無しさん
07/08/05 00:21:22
むちゃくちゃ関係あるだろ
545:デフォルトの名無しさん
07/08/05 00:55:50
つかadobe airがあるのに頑張る意味あんの？
546:デフォルトの名無しさん
07/08/05 01:02:35
Apollo自体に頑張る意味がないと思うんだが、それよりなぜJNIスレで？
547:デフォルトの名無しさん
07/08/05 08:49:12
>>541 君はJNIを一生障ることはないだろう
548:デフォルトの名無しさん
07/08/05 09:39:57
>>547
仕方なく使うだろ。
549:デフォルトの名無しさん
07/08/05 13:11:00
>>544 いまいちピンと来ない
550:デフォルトの名無しさん
07/08/05 15:52:33
JNIやると、.dllとか.soも理解しないと実質ダメだから敬遠される。
551:デフォルトの名無しさん
07/08/05 19:05:14
敬遠というか、JNIやるときにはDLLとかSO知らないと組めないことをやるわけだから・・・って書こうと思ったけど、DLL作るにしてもVBとかで手軽に書ければいいんだよな
552:デフォルトの名無しさん
07/08/06 08:43:38
mingwのgccでdllつくってる。clとかもそうだけど、コンパイラが吐くエラーメッセージが意味不明で泣きそうになる。javacの出来は優秀ってことが良く分かる。
553:デフォルトの名無しさん
07/08/06 08:58:16
cのリンク時に出るエラーで関数未定義とかで
どこにあるか分からないケースだと泣きそうになるな
javacも的外れなときはあるし
標準以外の機能を使い始めると
classpathが分からなかったり
色々苦労するよ
554:デフォルトの名無しさん
07/08/06 09:49:40
昔、メモリ搭載が128M程度のときに、1/2だと64M、1/4だと32Mなわけで
なんか身近な容量で実感があったけど、今のメモリ搭載が4Gであって、
1/2で2G、1/4で1Gで、メモリ確保としてやってることは変わらない。
2Gのメモリ確保って大きすぎるって感じはするけど、
当時はbmp,jpeg,mp3程度で10Mのファイルだったが、
今では、ISOファイルで700M、DVDで8Gとかのファイル読み込みになるんだから、
2G,3G程度のメモリ確保は普通にやるでしょ。
555:デフォルトの名無しさん
07/08/06 10:46:37
javaプロセス内で2G以上メモリ確保できるかなー
556:デフォルトの名無しさん
07/08/06 12:38:19
当然JavaVM外。
557:デフォルトの名無しさん
07/08/06 13:11:13
同一プロセス内じゃ無理じゃないかな
558:デフォルトの名無しさん
07/08/08 13:54:06
swigでラッパー自動的に吐き出して実装しようとしてるんすが、CStringとLPCTSTRとか、
各ポインタがSWIGTYPE_p_***となってしまってキャスト方法がわからんのですが、
JAVAでsuperclassとか意識しないでキャストする方法ありますか？
559:デフォルトの名無しさん
07/08/09 13:12:53
何をしたいのかよう分からん。
560:デフォルトの名無しさん
07/11/18 03:07:02
>>489
ここで紹介されているものもJNI並のオーバーヘッドがあるのかな？
だれかベンチとった人いないかな？
たとえ内部でJIN使っているとしても、JINとパフォーマンス的に大差ないなら
バッドノウハウなJINを使うよりずっとよさげだ。
561:560
07/11/18 03:08:39
JINって。。。吊（ｒｙ
562:560
07/11/18 03:13:34
ついでに
Javaってスタックオーバーフローとかアウトオブメモリとかでもfinallyブロックの実行保障ってされてるの？
563:デフォルトの名無しさん
07/11/18 04:13:29
StackOverflowError や OutOfMemoryError を特別扱いする記述が
JLSには見当たらないから、他の例外と同レベルに保証されてると考えて良いと思うけど。
ただまぁ、finally節で間接的にでもインスタンス生成した場合
即刻 OutOfMemoryError で死ぬって可能性はある。
564:デフォルトの名無しさん
07/11/18 04:27:18
>>563
.NETだとこれらの非同期例外についてfinallyブロックの実行保障がされてなくって
ネイティブリソースを扱う場合はSafeHandle等を使うわけだけども
JNIではVMがよろしくやってくれちゃうって認識でおｋ？
565:デフォルトの名無しさん
07/11/18 04:36:46
>>564
JNIが何で出てくるのか判らん
>>563はVM内での話でしょ？
566:デフォルトの名無しさん
07/11/18 04:37:07
SafeHandleみたいな場合は、JNI使う側でなんとかしろって事になると思うけど。
っつか、OutOfMemoryError も StackOverflowError も関係ないね、それ。
567:デフォルトの名無しさん
07/11/18 04:49:44
>>566
JNIの呼び出しでJava側がハンドルを受け取ってまたJNIでそのハンドルを引数にして呼び出したり
ってことはないの？
その際、JNIからJavaへ受け渡す合間に非同期例外が発生してもハンドルを喪失しない保障がないとやばいべ
568:デフォルトの名無しさん
07/11/18 11:41:44
>>567
メソッド呼び出しの際にチェックされるから、
JNI呼び出し前に非同期例外が発生していても問題ない。
JNIメソッド内で非同期例外が出る場合ってのも、
例えば OutOfMemoryError が出る前に、
まず NewObject や New<Type>Array みたいなメソッド呼び出し自体が失敗するから、
失敗した時点でJNIメソッド内で責任を持ってハンドルを解放しないといけない。
自動的にはやってくれない。
569:デフォルトの名無しさん
07/11/18 12:04:19
>>566
っつか、SafeHandle みたいな話なら関係ないのは finally だわな。
オブジェクトを生成して戻り値でハンドルを返すようなメソッド内で
オブジェクト生成したのに非同期例外で中断、戻り値じゃなくて例外飛んできて、
生成したオブジェクトのハンドルが失われてるから
finallyブロックの実行が保障されてても、解放したりの後処理ができねーってのを
防ぐための仕組みでしょ、SafeHandle って。
570:デフォルトの名無しさん
07/11/18 12:38:31
すまん。JNIっていうのに興味あるんだけど、ピアソンエデュケーションの本を
立ち読みしてみたんだけど、いまいちよくわからんのだ。JNIっていうのができると
たとえばどんな事ができるんだい？
571:デフォルトの名無しさん
07/11/18 15:19:24
C言語で書かれたライブラリなどがJavaから使えたりします。
572:デフォルトの名無しさん
07/11/18 15:27:10
>>568
なるほど。
JNIメソッド内でハンドル受け渡しを保障して、finally節実行も保証されているなら問題なさげだね。
>>569
SafeHandleはハンドル取得->代入のアトミック性と
SafeHandle自身がクリーンナップコードをもっていてその実行が保障される仕組み
じゃないっけ？だからfinallyが実行されなくてもリソースの開放が保障される。
finally節の実行保障がないからSafeHandleを使うってことで関係ないってことはなくね？
573:570
07/11/18 23:07:02
>>571 サンクス。なら、Windowsフォームつかって無理やりJNIプログラム作ってみるよ。
ありがとね。
574:デフォルトの名無しさん
08/02/29 02:19:26
C -> Java -> C みたいに変な感じでJNIを使いたいんだけど、
Java -> C のための loadLibrary() でDLLが見つからないんだ。
>>462 みたいなエラーが投げられてるみたいなんだ。
java.library.path で指定した場所にあるDLLなのに。
ちなみに、C -> Java の部分をなしにして、直接javaから
起動すると loadLibrary() できるんだ。
あと、sun.boot.library 上に置いてもうまくいくんだ。
JDK1.5.0_10 + Windows XPなんだけど、誰か何か知らない？
575:デフォルトの名無しさん
08/02/29 22:59:06
>>574
それ解決できないレベルが触らない方がいいものだよJNIは
576:デフォルトの名無しさん
08/03/09 01:39:10
JVMTI でツール作ってる。
JNI 部分(A)＋Java 部分(B)と、テスト用の Java ター
ゲットプログラム(C)が用意してある。
起動時に指定されたクラスメソッドに対して
RedefineClass() 使って(B)のクラスのスタティックメ
ソッドを呼び出すバイトコードを inject してる。
で、(C) のクラスを指定すると期待通り動くんだけど、
java のライブラリクラスを指定すると (B) クラスの
NoClassDefFoundError になってしまう。
環境は Linux+JDK5 なんだけどこれってどうして？どう
したらいい？
ちなみに Java 歴一年です。
577:デフォルトの名無しさん
08/03/09 01:56:29
どうしても糞もNoClassDefFoundErrorだろ。
今時JNI使おうって奴はこんなレベルなんかね・・・
578:576
08/03/09 01:59:56
>>577
実行環境は全く一緒、実行するプログラムも引数も全く一緒で、
inject してるバイトコードが参照してるクラスも一緒。
ターゲットプログラムのクラスからは見えるのに
ライブラクラスから見えないのはなんで?
579:デフォルトの名無しさん
08/03/09 02:11:02
クラスローダが違うとか？
580:576
08/03/09 02:40:45
了解。ちょっと調べてみる。
581:576
08/03/09 03:49:36
うーん、ちょっと手を入れてる暇がないなぁ。
当初の目的は果たしたし、とりあえずライブラリ側は
どうしても必要なら後から考える。
> 今時JNI使おうって奴はこんなレベルなんかね・・・
いや、これはもう本当にその通り。
JNI なんて触るより前に知っておくべきことだった。
582:デフォルトの名無しさん
08/07/22 19:57:59
583:デフォルトの名無しさん
08/07/22 20:38:03
TextSS
584:デフォルトの名無しさん
08/08/13 22:30:08
C++からJavaのnativeなメソッドに char* を返したいのだが、
jbyteArrayとかにしないとJava側で受け取れないかな？
char* のままで返せない？
585:デフォルトの名無しさん
08/08/13 22:53:38
>>584
せめて整数型にキャストするとかしないと無理。
586:デフォルトの名無しさん
08/08/13 23:32:29
>>584
っていうか char* を jbyteArray にどうやって変換するの？
587:デフォルトの名無しさん
08/08/13 23:36:45
NewDirectByteBufferという手も
588:デフォルトの名無しさん
08/08/13 23:58:38
そんなことできるんだ
589:デフォルトの名無しさん
08/08/14 00:01:29
>>587
馬鹿なおいらに具体的なサンプルコード書いてください、仏様。
590:デフォルトの名無しさん
08/08/14 01:26:18
こんな感じ？
#include <jni.h>
JNIEXPORT jobject JNICALL Java_Goodbye_getGoodbye(JNIEnv *env, jclass clazz) {
return (*env)->NewDirectByteBuffer(env, "goodbye", 7);
}
import java.nio.*;
public class Goodbye {
public static void main(String[] args) {
System.loadLibrary("goodbye");
ByteBuffer buffer = getGoodbye();
byte[] b = new byte[buffer.remaining()];
buffer.get(b);
System.out.println(new String(b));
}
private static native ByteBuffer getGoodbye();
}
591:デフォルトの名無しさん
08/08/14 08:30:15
>>590
NewDirectByteBuffer って読み書き両用にしかできないと思ったが、
C/C++ の文字列リテラルって書き込みして良いんだっけか？
592:デフォルトの名無しさん
08/08/14 09:27:52
え、read onlyのdirect bufferって作れないの
593:デフォルトの名無しさん
08/08/14 09:46:01
asReadOnlyBuffer() すりゃ読み込み専用にできるけど、
NewDirectByteBuffer した直後は書き込めるよね。
594:デフォルトの名無しさん
08/08/14 09:51:42
あぁ、asReadOnlyBuffer しても読み込み専用のビュー返すだけで
NewDirectByteBuffer で作成したバッファ自体が読み込み専用になるわけじゃないんで。
595:デフォルトの名無しさん
08/08/14 10:10:12
>>590だけならNewStringとかNewStringUTFした方が楽じゃね
NewDirectByteBufferに自前で確保したメモリ渡す時って
誰がどのタイミングでメモリ解放すりゃいいんだか良くわからんし
メモリ解放用のコールバック関数渡すわけでもないみたいだし
NewDirectByteBufferってメモリマップドI/Oみたいな
解放の必要がないアドレス渡すためにあるんじゃ
596:590
08/08/14 12:11:38
サンプル欲しいっていうから書いただけなんだからねっ
使い方に問題あるのは百も承知
>>595
一度放ったByteBufferを無効に出来ないってのがネックなんだよな
参照が切れてGCに回収されるのをWeakReferenceで待ってから解放するしかない
597:デフォルトの名無しさん
08/08/16 21:24:14
問題の少ない使い方するために記述容易性なくなるんなら
素直に byte[] とか使った方が早いんじゃねーかと思わなくも無い。
598:デフォルトの名無しさん
08/08/17 11:27:03
>>598
URLﾘﾝｸ(imepita.jp)
599:デフォルトの名無しさん
08/09/02 07:29:06
>>596
よく頑張った。参考になった。
600:デフォルトの名無しさん
08/09/13 00:46:19
ああああ デバッグ面倒くせええええ
601:デフォルトの名無しさん
08/10/07 08:19:19
>>401
∧ ∧ 彡
ミ ( ^ω^ )っ 彡
Ｏ ノ ﾀﾀﾀﾀ…ｽｹﾞｰ
ミ| (_) 彡
ミ し´ 彡
602:デフォルトの名無しさん
08/11/06 19:01:15
現在とあるマイナーDBMSをJavaから利用するために、DLLで配布された
ドライバをSWIGでラップしてJDBC環境もどきを実現するライブラリを開発
しています。
現在開発環境上ではちゃんと動作するのですが、作成したライブラリを
ドライバのDLLやJNIのDLLと一緒にJARとしてパッケージングして配布
しても、配布先で動作させる事が出来ません。
過去レスではJARにネイティブライブラリを組み込むのは無理、との回答
でしたが、Googleで調べてみるとJARにdllやsoを組み込むには、
「manifest.cfにBundle-NativeCodeなる項目を追加してファイル名を列挙」
すれば良い、みたいな情報を見つけました。が、これでも無理でした。
これはもう無かった事になっているのでしょうか？
603:デフォルトの名無しさん
08/11/06 19:21:33
Bundle- って OSGi では？
普通の Java アプリケーションには無意味なプロパティ
604:デフォルトの名無しさん
08/11/13 00:50:18
JNI で呼び出すDLL(C++でコーディング)で、
int* src = (int *)env->GetPrimitiveArrayCritical()
__m128i * s128 = (__m128i *)src;
__m128i const128 = _mm_set1_epi32(1);
*s128 = _mm_sub_epi32(*s128, const128);
みたいなことするとVMがクラッシュしてくれて泣きそうです。
DLL側でメモリリークしてるとクラッシュするんで、それと同じかなぁと
おもっとるんですが、
GetPrimitiveArrayCritical じゃなくて、普通に
_mm_malloc() して確保した場合は問題ないんですよねぇ。
JNI の先で SIMD 命令使ったことある猛者はおらんですか。
605:デフォルトの名無しさん
08/11/13 02:02:15
クラッシュしたときの例外コードは？
_mm_malloc()で動作するということはalignじゃないの？
606:デフォルトの名無しさん
08/11/24 14:43:19
>>604
どのコードでクラッシュするんだよ？
そのコードの中か？
それとも、そのコード抜けて、しばらくたってからか？
後者なら、おまえの書いたC++コード中か？それとも、ＪａｖａＶＭのコード中か？
607:デフォルトの名無しさん
08/11/24 14:46:17
つか、GetPrimitiveArrayCriticalって、Javaヒープの中身を指してる
ポインタを返すと思うから、下手な操作すると、Ｊａｖａヒープぶっ壊して
簡単に死ぬぜお
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使うような場面が減ったんだろう
まあいいことだ