[Java SE 7] 次世代Javaの動向 5 [dolphin]

1 名前：デフォルトの名無しさん [2007/05/12(土) 08:25:15 ] 前スレ [mustang/Java SE 6] 次世代Javaの動向 4 [dolphin] pc11.2ch.net/test/read.cgi/tech/1163986696/ [mustang] 次世代Javaの動向 3 [dolphin] pc8.2ch.net/test/read.cgi/tech/1157227790/ 次世代Javaの動向　２ pc8.2ch.net/test/read.cgi/tech/1147881822/ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/ 136 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:37:07 ] 標準で入ってないと意味ないし、無駄な努力なのだが。 137 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:40:17 ] SPI使えるんだから、クラスパスに含めるだけで新しいスクリプト言語使えるようにできるんだが…… 138 名前：デフォルトの名無しさん [2007/08/01(水) 22:42:38 ] おれは、C言語をスクリプトで実装して欲しいぜ！ それもC99を！ 139 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:45:08 ] >>137 ん？俺が無知なだけなのか・・ 140 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 23:13:33 ] まあ実際無知なんだろうな。 141 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 05:09:30 ] >>135 いや、オレもRhinoしか添付されてないと思ってたのだが、それだと野良スクリプトエンジンの方が品質がいいってのがひっかかる。 Rhinoよりいいスクリプトエンジンって何だ？ 142 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 05:10:04 ] >>136 いらん。 143 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 12:28:23 ] >>141 普通にビルドしたRhino。 144 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 14:28:20 ] >>141 つ　Pnuts 145 名前：デフォルトの名無しさん [2007/08/03(金) 00:08:05 ] >>138 個人的にはFORTRANが良い 146 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 00:12:18 ] たしかSunがFortressっての開発中だったと思う。 並列計算に特化したJavaとFortranを参考にしたスクリプトっての。 147 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 00:12:52 ] >>144 pnutsそんなにいい？ まだこなれてない感じバリバリなんだけど。 yieldの挙動とか。 148 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 04:44:27 ] あんま関係ない話で恐縮なんだけど、javax.script バブルの火付け役が php だって噂は本当なん？ 149 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 06:10:32 ] msのcliに対抗するため 150 名前：デフォルトの名無しさん [2007/08/03(金) 06:16:58 ] C言語やC#にある値型の struct はいつサポートされるの？ 151 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 08:37:18 ] >>148 script言語の共通基盤になるチャンスを見逃すわけがない。 javascript, php, python, ruby実装環境をごっそり頂きかも知れない。 コンパイラ基盤もちらほら出てきているし。 152 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 12:00:15 ] >>150 なぜそんなものが必要なのか？理由を明確に 153 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 12:54:23 ] リンゲージがその関数内であるオブジェクトに対して、イチイチnewしないで済むことが言語として保障されることになる。 154 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:02:33 ] >>153 コンパイル時に最適化情報がバイトコードに埋め込めればいいんだよね〜 そしたら、ガンガンエスケープ解析できる 155 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:28:43 ] >>151 いや、知り合いから 「php を java vm 上で動かそうって話が最初で、そのあと他の軽量言語が追従した」 って話を聞いたんだけど、本当なのかなって。 156 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:54:15 ] >>154 そういう小手先解析よりも、普通に言語としてサポートしろってこと。 struct Point { double a,b }; どう考えても需要あるだろ。 157 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:56:16 ] >>155 それだけ需要があるなら、PHPがまずサポートされるはずじゃないか？ VMで他の言語が動けばいいのであって、どうでもいいけど。 158 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 14:24:28 ] >>156 その程度なら不要。 値型の利点は、newが必要とかより、 代入が必ずコピーになることによって、 同一オブジェクトに対応する変数が一つであることを保障できることだと思うんだが。 159 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 16:26:23 ] >>158 需要の論点ではPointで示したが、利点としては例えが悪かった。 では必ずコピーになる利点のために導入するのではどうだ？ほしいだろ？ 160 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 16:41:03 ] いや別に 161 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 17:45:57 ] 値型が導入されたら、今度はポインタ演算を欲しがるに違いない 162 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 19:10:24 ] C#はstructの導入に失敗したからNullableが出来たんでしょ 恥ずかしい実装まで追従する必要ないから、別に要らないなぁ どうしてもってのならByteBufferをラップすりゃいいし 163 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 19:34:17 ] 値型ってメモリ効率に関する利点のために導入するもんだろ。 164 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 19:36:02 ] それが理由ならエスケープ解析が導入されたから今後は不要でしょ 165 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 21:11:05 ] >>161 それはない。 166 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 21:17:46 ] >>164 複雑じゃなくていいから、普通にCと同じのでいいよ。 メソッドもCの関数ポインタみたいに、staticのみでいい。 エスケーポ解析よりも言語に導入のほうが楽だと思うけど、そうでもないのか まあ、そのうちちゃっかり導入されるんだろうけど。 167 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 22:14:07 ] JDK7 build17 ttp://download.java.net/jdk7/changes/jdk7-b17.html ttp://download.java.net/jdk7/binaries/ 168 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 00:41:24 ] いまさら導入されても、C の register 変数と同じ運命をたどる予感。 169 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 02:00:02 ] register にも、一応アドレスを取れないという効果はあるんだぞ！ 170 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 07:19:54 ] >>157 PHPみたいなどうでもいい言語をまずサポートする必要性がみあたらない。 171 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:47:45 ] structのメモリー効率のよさってのは、オブジェクト廃棄時のコスト云々じゃなくて、 newに頼ってオブジェクト生成するときのコストがまったくないってことだろ。 関数呼び出しでスタックに自動生成されるのであって、newによるオーバーヘッドは かからないいってこと。 172 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:51:14 ] オブジェクトがほかのメソッドに伝播される可能性を考えると、エスケープ解析で自動的にやってくれるのが一番効率がよさそうだな。 173 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:52:09 ] structは、コピーによって、ここのオブジェクトの同一性の確保も そのとおり利点ではあるが、エスケープ解析の小手先技なんぞに頼らないで 優先的に言語でサポートするのが妥当だろ。 assert, enumとかよりも先にさ。 Javaの文法は、結局Cの文法を真似てるだけってことを忘れて、 「エスケープ解析もできる俺ってすごいだろ」っていい気になってるだろ？ 174 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:52:42 ] エスケープ解析ってのはそれをやるんだよ。 C#のstructと同じような最適化がされることになり、 逆にC#2.0で対応するはめになったNullableのようなstructの欠点も無い 175 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:54:47 ] >>171 まあ、メリットはあっても、それが"大きく"効いてくるのはかなり特殊なケースで、 そういうのが大量にある応用の時は、ハイバネでいい、ってのが今の流れなんじゃないの? 176 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:55:56 ] JavaのenumはCのenumとは違うぞ。 定数そのものに振る舞いを持たせることが出来るし、 なおかつタイプセーフだ。 177 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:57:25 ] メモリーの効率とかじゃなくて、 structを使いたいプログラマーの切実な要望には答えられないのかね？ そういうエスケーポ解析の新技術はどうでもいいからさ。 178 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:58:34 ] >>173 で、エスケープ解析に比べたstructの利点ってなんなの？ 179 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:58:58 ] structの欠点の無いむしろメリットとなるようなカラクリがあれば導入されるかもな。 180 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:02:12 ] ちなみに、structなど値型を使いたい場面は、 forや関数呼び出しで100万回以上まわす。 そういう小型オブジェクトの短期生成は、newでは向いてないし、役不足だろ。 またエプケール解析とかいうのか？ GCの新技術はJava以外のVM使うスクリプトにもメリットあるだろうが、 そういうのは使うほうからみてどうでもいいから、まずはJava言語で導入しろ。 181 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:02:38 ] >>177 メモリーの効率とかじゃないなら、structを使いたいっていう切実な要望っていうのは、新技術以上にどうでもいいんじゃないかと思う。 182 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:03:54 ] >>180 使う方から見てどうでもいいのがstructだと結論づいてるのに何を・・・ 183 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:04:17 ] >>176 使うほうからすれば、C,Javaどちらのenumも同じ。 いつ使えるようになったかといえば、Javaはサポート遅すぎ。 184 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:04:37 ] >>180 エスケープ解析で十分です。どうもありがとうございました。 185 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:05:49 ] >>183 全然違うっての。お前のいう「使う人」って誰だよ。お前限定じゃねーか。 お前はCだけ使ってろ。 186 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:06:52 ] >>181 きみ、structとclassは実質同じってことを知ってるのか？ 187 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:08:35 ] >>186 C++のデフォルトアクセスレベルの話で言ってる？ 同じものなら要らないだろ 188 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:09:11 ] structを否定するってことは、classつまり、構造体型（集合型）を否定しているようなものだけど・・ 君の理解じゃ、ポインタがどうとかってあたりで止まってるんだろうな。 189 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:09:20 ] >>186 だから、なに？メモリ効率以外に、structの利点ってあるの？ 190 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:10:21 ] >>188 なんで？ きみ、エスケープ解析の意味ちゃんとぐぐってる？ 191 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:15:05 ] なんか、エスケープ解析をわかってないやつがいるみたいなんで書いておくけど for(int i = 0; i < 10; i++){ 　Point p = new Point(); 　p.x = i * 2: 　p.y = i * 4; 　System.out.println(p.x + ":" + p.y); } が for(int i = 0; i < 10; i++){ 　int px = i * 2: 　int py = i * 4; 　System.out.println(px + ":" + py); } に最適化される技術な。 192 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:34:02 ] まとめると、「エスケープ解析の意味がわかんないやつが暴れてましたとさ」でいいの？ 193 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 10:12:30 ] >>180 エプケール解析て…これは釣りだろ。 それから値型もnewされることに変りはないぞ。 194 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 10:20:21 ] Java版のaptみたいなのがそろそろ出てきてもいい頃合だね。 各種IDEやmavenの資産、そしてJAMの登場によって下地は十分のはず。 JDKに同梱されれば、環境構築のコストが激減しそう。 195 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 11:09:02 ] SunがOpenSolaris用のパッケージ配布機構を発表したぞ。 ZFSに基づくサービス、実装らしい。 Sun、『OpenSolaris』でバイナリパッケージ配布モデル採用へ japan.internet.com/busnews/20070713/11.html 196 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 11:55:05 ] またエスケープ解析が得意の彼か 彼の言い分も一理あるが、単純に彼は自分の技術を自慢したいだけだから、ほっとけ 197 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 11:55:58 ] >>193 そもそも struct とか言う奴は大抵釣り。 198 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 12:01:23 ] JOGLやjinputとかをJDKから簡単に取り寄せられたら便利だね 199 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 12:18:37 ] 下手にやると複数バージョンのjarが入り混じってカオスになるけどね 200 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 12:25:12 ] >>196 そういう話は、的確な議論してから言ったほうがいいと思う。 201 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 13:47:09 ] struct ： スタックに値を割り付ける エスケープ解析 ： スタックにオブジェクトを割り付ける最適化手法 オブジェクトが対象のエスケープ解析の勝ちでおｋ structは時代遅れの産物 202 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 14:13:45 ] >>196 自分の視点でしか判断できないのが彼のような技術者ってもんだし、 他人の要望とかまったく無視で自分の技術一点張りだな、こいつは。 つまりは、一人でコソコソとエスケーポ解析してろってこったな。 あー、ねくら、ねくら 203 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 14:17:20 ] >>201 おまえはばかか？勝手にしこってろ。嫌ならCをべんこうしなおせな。 204 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 14:22:58 ] >>202 C C++ アセンブラのときでも、小手先技使って最適化大好きって輩がいるけど、こういう根っからの技術者って人の話聞かないしね。こういうねくらは、あんまり表にしゃしゃり出てこないで中にこもって解析していて欲しいよ。 205 名前：デフォルトの名無しさん [2007/08/04(土) 14:31:59 ] 有能な学生をいじめたらだめれす！ 206 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 14:36:57 ] >>201 おまえのその論理だと、Java標準のlong doubleなどプリミティブ型は時代遅れなのか？ そして解析手法を駆使する方が今風なのか？ おまえ、そんなことしてるよりコンパイラ作ってみろ。そうすれば分かる。 207 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 14:39:43 ] >>206 暇ならコンパイラとVMに struct実装して OpenJDKあたりにパッチ送ってみれば？ どれぐらいメモリ効率が良くなるかみたいなデータも示せば採用されるかもよ？ 208 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 14:46:21 ] >>206に コンパイラやVMを書き換えるだけのスキルがあるとは思えないが 209 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 17:08:16 ] ひさびさに高品質の夏厨があらわれたな。 210 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 21:46:11 ] >>173 ＞「エスケープ解析もできる俺ってすごいだろ」 惚れました 211 名前：デフォルトの名無しさん [2007/08/05(日) 00:44:29 ] >>191みたいな馬鹿に突っ込める奴は、 ここにはいないのかｗｗｗ エスケープ解析とは、ソースコードを解析してバイトコードの最適化を行う話じゃない。 Javaのコンパイラはソースコードとバイトコードの対応付けが規定されているので、 そもそもバイトコードの最適化はありえない。 メソッド内で生成されたインスタンスが、 メソッドの外へ「逃げるか逃げないか」を判断する技術だ。 returnや引数やフィールドに参照が渡されるコードがあれば、 「メソッドの外に逃げる」と判断されて、 インスタンスはヒープに確保される。 逆に「メソッドの外に逃げない」と判断されたら インスタンスはスタックに確保される。 わかったかいｗｗｗ？>>191 212 名前：デフォルトの名無しさん [2007/08/05(日) 00:44:39 ] くそ天皇　くそ天皇　くそ天皇　くそ天皇 いい加減死ねっつってんだろ屑ニートくそ天皇が 相変わらず病的な粘着っぷりだな屑ニートくそ天皇が 毎日毎日毎日粘着出来て良いでちゅねくそ天皇 くそ天皇さっさと死にやがれゴミが 東京に在住している精神病珍米糞ニートくそ天皇君の末路 さっさと精神病院逝くか首吊って逝くか選べや糞天皇が 早く死ねよ糞ニート天皇が 粘着精神病屑ニート天皇君は自らニートくそ天皇であると公言しました さっさと死ねやくそ天皇が 早く死ねっつってんだろ屑ニートくそ天皇が お前みたいなゴミクズ天皇は息してるだけで空気が汚れるからさっさと死ねや とっと死に晒せや糞ニート天皇が 213 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 01:22:48 ] >>211 引数に渡すだけでもエスケープと判断されるのか。 オブジェクトの生存期間がスタックのそれに制限されているだけじゃだめなのね。 214 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 01:30:19 ] 渡したメソッドがインライン展開されてれば大丈夫 渡した先でそのオブジェクトがどこに保持されて生き延びるかわからんからね 215 名前：デフォルトの名無しさん [2007/08/05(日) 01:32:40 ] >>213 引数がListで、そのListに生成したインスタンスを追加したりとか。 216 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 01:33:12 ] >>214 それってつまり実行して見るまで分からんってこと？ 217 名前：デフォルトの名無しさん [2007/08/05(日) 01:35:41 ] エスケープ解析の間違ったネタが書き込まれているし・・・ それに誰も突っ込まないし・・・ そもそもエスケープ解析は次世代ネタじゃないし・・・ 終わってね？ 218 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 01:38:48 ] 当時の流れて下手に突っこんだら粘着に餌与えるだけだけどな 219 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 01:40:32 ] >>216 HotspotVMは実行時にコンパイルするんだから大丈夫 220 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 09:39:23 ] >>211はここを見るべき www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml 221 名前：デフォルトの名無しさん [2007/08/05(日) 10:18:29 ] >>220 おまえ191だろｗｗｗ そんな記事は知ってるわ。 そもそもインライン化とエスケープ解析は違う。 222 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 13:22:13 ] >>211 > Javaのコンパイラはソースコードとバイトコードの対応付けが規定されているので、 > そもそもバイトコードの最適化はありえない。 （　ﾟдﾟ）ﾎﾟｶｰﾝ 223 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 14:45:58 ] >>221 そうだね、エスケープ解析した結果として、スタックアロケーションしたりインライン化したりするんだね。 違う階層の言葉だったね。 224 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 14:47:26 ] if(true)が無視されてバイトコードに埋め込まれないのは、バイトコードの最適化といわないのかな。 225 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 14:54:08 ] メソッドに仮実装がある場合で、その処理を通さずメソッドの先頭で値だけ返したい場合とか if (true) を未到達エラー回避にたまに使うな。C#はboolを変数化しなきゃいけなくて面倒だ。 ああ、まるで脱線した話題だけどね。 226 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 14:59:07 ] インライン化はエスケープ解析の結果じゃないけど、まぁいいや。 もうちょっとスレタイトルにふさわしい話題ないの 227 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 15:02:44 ] ならクロージャとJAM以外で見所のある機能があれば紹介して。 228 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 15:03:08 ] template萌えな私を叱ってください。 229 名前：デフォルトの名無しさん [2007/08/05(日) 16:24:56 ] JITは標準のコンパイル結果に対して最適化するように動くので、 バイトコードへコンパイルするときは、 明らかな最適化が可能なもの意外は何もしないよ。 バイトコードへコンパイルする時に、 Javacが生成しない最適化されたバイトコードを生成すると、 JITは最適化の対象外になるからかえって遅くなる。 Javacを無視してバイトコード生成するのはJikesぐらい 230 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 16:29:39 ] ん？javacって最適化方針まで規格化されてるの？ 231 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 16:31:19 ] 規格化なんかされてないでしょ。 特定の実装の話じゃないの？ 232 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 16:33:24 ] javacが生成しない最適化されたバイトコードって話がどこからでてきたのかがわからん 233 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 17:44:13 ] そもそも今のjavaの動的コンパイル技術はJITじゃなくてHotSpotだろ。 >>141 jdkのRhinoはMozillaのRhinoコードが実行できないほどの超絶劣化品。 あれらのエンジン間に互換性はないよ？ Rhinoの実装ライブラリがsun.*パッケージに移動されてるから Rhinoに含まれるセキュリティーライブラリがどの常に利用できるとも限らんし、 バイトコード吐かないから常にインタプリタモードで動いて遅いし。 E4Xないし。上げ出したら切りがない。 234 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 21:45:36 ] >>233 HotSpotは、実行時間食ってる箇所を見つけてJITコンパイルする。 もしくは、あんまし実行されない箇所のJITコンパイルを抑制する。 大雑把な議論をする場合はJITでもHotSpotでもどっちでも良い。 変な拘り持ってる奴を相手にするんでなければ。 235 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 22:06:34 ] 3回動くとコンパイルが走ると感覚的に判断してるから、 ベンチマーク前は、10回は回してからやってる。 server vmってのは何時間も動かすと更に最適化されたりするんだろうか 236 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 03:18:49 ] >>234 でもそれって最適化方法が同じ実装の場合に限られない？ サーバー向けVM製品とかの中にはHotSpotと同じ適応型最適化コンパイルするけどVM実装の都合で あえて変わったタイミングでコンパイルしたりする奴居るよ。 >変な拘り持ってる奴を相手にするんでなければ。 てのはこいつらのこと？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef