[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/ 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実装の都合で あえて変わったタイミングでコンパイルしたりする奴居るよ。 >変な拘り持ってる奴を相手にするんでなければ。 てのはこいつらのこと？ 237 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 08:15:35 ] >>235 感覚に頼んじゃなくて -XX:+PrintCompilation とか -Xbatch とか使ったほうがいいと思うけど 238 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 09:30:04 ] >>236 一切JITコンパイルしない最適化方法の事をJITって言ってたら 話が通じなくなるから問題だけど、タイミングが変わるぐらいなら問題ないでしょ。 239 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 11:41:02 ] >>236 > あえて変わったタイミング kwsk 240 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 16:57:02 ] >>239 たまたま見つけたんで製品名は知らんが アプリケーションが１度走り出したら負荷のかかるGC/動的コンパイルを 徹底的に発生させないために実行初期にとっとと見切りプロファイルしてマシン語吐いちゃってシステムの稼働を優先させるタイプのVMをどっかで見た。 でも、実行初期段階からボトルネック見つけたりパフォーマンスを平均化する技術を使ってるらしくAOTじゃないみたい。 民生用じゃないVMなんかはそういう変わった実装見るよ。 >JITコンパイルしない最適化方法の事をJITって言ってたら MEベンダの中にはただのインタプリタ最適化を"独自の"JIT技術と呼んでるところもあるんだなｗ 漁ると結構変なVMっていっぱい。 あと、JITをただの動的コンパイル（OR最適化）のことだと思ってる奴とか。 241 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 17:00:03 ] 語義的には Just In Timeで何かしてたら、なんでもJITになるわな。 242 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 17:23:51 ] JITコンパイラと名乗ってなければ、 > ただのインタプリタ最適化を"独自の"JIT技術と呼んでる なんの問題もないだろ。 243 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 15:30:39 ] JSR-308に関してこんなん見つけた。 pag.csail.mit.edu/jsr308/ 正式リリースからは削除予定だけど、JDK7の開発期間中は暫定的に、 /*@Readonly*/ Object x; みたいのがあると、アノテーションとして認められるらしいんだけど、 これJDK6以前とJDK7以降で共用のライブラリ書くとき便利だから 言語仕様として残して欲しかったり…… JMLみたいな既存のツールが既に/*@...... */ ってタイプのコメント使ってるので 言語仕様に組み込むのはダメって話らしいんだけど。 244 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 03:26:00 ] コメントに書くのは邪道。 245 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 19:26:13 ] >>243 そーゆー事やりたいんだったら、JDK7以降用にソースを書いておいて、 Tree API とか使ってアノテーション落とした方が良いかもね。 246 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 11:58:02 ] エスケープ解析って、*.javaを解析するのか、*.classを解析するのかどっちなの？ 247 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 12:35:59 ] >>246 .javaはまず無い。バイトコードにスタックにオブジェクトアロケーション する命令なんか無いんだから。おそらくバイトコードをJITコンパイルする 段階でエスケープ解析していると思われる。 248 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:00:12 ] >>243 > @Readonly Object x; > if (x instanceof Date) { ... } // error: incompatible annotations > if (x instanceof @Readonly Date) { ... } // OK > Object y; > if (y instanceof Date) { ... } // OK > if (y instanceof @NonNull Date) { ... } // error: incompatible annotations これ必要なんだろか？ 型アノテーションってインスタンス毎に ついてるわけじゃなくてerasureなgenericsと同じような扱いでしょ。 こんなん付けても無駄に長くなるだけなんじゃ…… 249 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:10:08 ] エスケープ解析って、 ＞バイトコードをJITコンパイルする 段階 の技術だったのか。よくわかった。 ただ、「思われるとか」憶測で語っているのはどうかと。 250 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:32:15 ] 思われなくても、JITコンパイル時の処理です。 251 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:47:33 ] >>248 if (list instanceof ArrayList<String>) { ... } とかはコンパイルエラーになるのにな。 一貫性がないっつーか…… 252 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:49:34 ] >>250 よくよくわかった。 253 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 14:00:37 ] >>243 なんつーか互換性重視だった 1.5 までと、 どっちかっつーと互換性軽視 機能追加重視の最近の風潮で ねじれが出てるような気もする。 こんぐらい無節操に機能追加される（予定だ）とプリプロセッサ使いたくなるよな。 >>245 のも発想的にはプリプロセッサだし…… 254 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 14:30:29 ] アノテーション使わなければ、互換性あるんだからいいんじゃね？ 255 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 14:36:28 ] どの互換性を軽視だって？ 256 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 14:45:12 ] >>255 write once compile any version が出来ない、 もしくは無理にやろうとすると、新機能使えなくて不便になるって話。 257 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:03:26 ] 内部でクロージャが使えない、とかは我慢すれば良いとしても 古いバージョンもサポート対象に入ってて JSR-308みたいのが使えないと 新バージョンで使う時に型情報が減るからな。 258 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:22:20 ] >>256 （　ﾟдﾟ）ﾎﾟｶｰﾝ 259 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:38:30 ] >>256 まぁ、言語として複数バージョンに対応するための配慮なんかは一切無いな。 #ifdef 使えばソース汚くても複数バージョンに対応できるみたいな救済策もないし。 260 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:39:23 ] 相手に合わせようとするのは、JAVAらしくないな。 逆に、相手がJAVA（JVM）に合わせろってところにJAVAの互換性がある。 261 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:40:54 ] >>256 クラスワーキング・ツールキット: 古いJVMでJ2SE 5.0の機能を使う www-06.ibm.com/jp/developerworks/java/050819/j_j-cwt07065.shtml JavaのGenericsに関しては、上位互換性(下位互換性ではなく！)を満たすために Erasure方式で実現したから、コンパイルオプション指定でJDK1.4でも動くはずだが。 262 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:40:54 ] >>257 まず型ありきの言語で型情報減るのは痛いよな。 263 名前：261 mailto:sage [2007/08/09(木) 16:02:17 ] javac -source 1.5 -target 1.4 Test.java javac: リリース 1.5 のソースにはリリース 1.5 のターゲットが必要です。 と言われてしまった。偽情報スマソ。 一応、Retroweaverを使えば可能なようだが．．． Retroweaver supports most 1.5 features while running on 1.4. * generics * extended for loops * static imports * autoboxing/unboxing * varargs * enumerations * annotations JDK1.4でコンパイルされたライブラリを、 JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．． というかこれが無理なら何のためのerasure方式採用なんだよって感じだが。 264 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 16:02:53 ] >>261 -target jsr14 だっけ？ 文書化されてないんだよね、これ。 265 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 16:05:35 ] >>263 > JDK1.4でコンパイルされたライブラリを、 > JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．． 可能っちゃ可能だけど、パラメタ型の情報無いよ 266 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 16:14:57 ] >>264 -target jsr14を使うと可能でした。ｔｈｘ。 Java の理論と実践: Java 5 の言語機能を以前の JDK で使う www-06.ibm.com/jp/developerworks/java/library/j-jtp02277.shtml 列挙型以外はほぼ問題ないようだ。 267 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 17:24:49 ] >>266 JDK5以降のライブラリや、メソッドを使うときに注意。 Autoboxingなどはちゃんと処理される。 268 名前：デフォルトの名無しさん [2007/08/10(金) 01:25:21 ] win32 apiとか触るの面倒だし、だれかjvm上で.netが動くの作ってくれないかな C＃をインタプリタ実行するのでもいいからさ 269 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 01:26:53 ] >>268 それはそれで凄まじいな ……考えてみるか。 270 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 01:51:45 ] C# を Java バイトコードにコンパイルする方が楽じゃない？ 271 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 02:08:05 ] エスケープ解析は、*.javaに対して行っておくほうが実行効率がいいけど、その情報を*.classに残す手段がないので、実行時の最適化でしか使われていない 272 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 02:12:52 ] >>249 >>247だが、実際にソースまで追って確認したわけじゃないので そういう表現になっただけで、JITコンパイル段階でやってるのは ほぼ間違いないよ。まあ、厳密に言えばインタープリタモードでも やってる可能性もあるけど、メリットが考えられない。 273 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:03:50 ] 手段がないわけじゃないと思うけど。 stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。 ただ、静的に解析しても効果が弱いと思う。 メソッドの非仮想化やインライン展開を終えた後にやる方がいい。 274 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:17:31 ] >>273 それは、メソッドの非仮想化とインライン展開がエスケープ解析に与える影響がすごく大きいってこと？ そうは思えないんだけど。 275 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:46:33 ] >stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。 これは上で出てきたstructをJava言語でサポートするんじゃなくて、 JVMでサポートするってのに実質的に近いんじゃないか？ 276 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:55:03 ] >>274 例えばさ、 public Object[] foo() { Vector v = makeVector(); v.add("bar"); v.add("hoge"); return v.toArray(); } public Vector makeVector() { return new Vector(); } みたいなコードがあったとするじゃない。 (例がやや作為的だけど、そこは目を瞑っていただきたい。) いっけん v は foo の外にエスケープしてないように見えるけど、add とか toArray とかの中で this をどこかの static 変数に保存しているかもしれない。 誰も Vector クラスのソースを見たことあるわけじゃないし (あるかもしれないが)、 Vector がそういう変な実装になってないとは断言できまい？ そういうわけで、この時点では v をスタック上にアロケートしてしまうわけにはいかない。 (this をどこかの static 変数に保存したりできなくなってしまう。スタックは foo を抜けたら消滅するんだし。) でも add とか toArray とか makeVector とか Vector コンストラクタを全部インライン展開できれば、v が foo の外にエスケープしてないかどうかがはっきりする。 エスケープしてないと判れば、もう別に Vector を new する必要なんかなくなって、 Vector の全フィールドをみんなスタック上に展開してしまえる。 makeVector は final じゃないから実はオーバーライドされてて他のクラスを返してるかもしれないが、これも非仮想化されてればインライン展開できる。 ・・・って思ってるんだけど、現実のJVMがどこまでやってるかは知らない (´･ω･`) 277 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 04:44:16 ] >win32 apiとか触るの面倒だし ここらへんあるから実質C#はマルチプラットフォームじゃないよね。 278 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 09:53:41 ] >win32 apiとか触るの面倒だし それだけだったら、win32 api を触らなくて済むようなGUIフレームワークとかを使えばいいだけと違うん？ 279 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 09:56:34 ] >>273 > ただ、静的に解析しても効果が弱いと思う。 > メソッドの非仮想化やインライン展開を終えた後にやる方がいい。 二行目は静的/動的と関係ないじゃん。 280 名前：278 mailto:sage [2007/08/10(金) 09:57:41 ] って、.C# か・・・ じゃあ GTK# とか・・・ びみょかな・・・ 281 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:35:35 ] >>279 静的に＝.javaのコンパイル時にって意味で書きました .javaコンパイル時に非仮想化・インライン展開とかできないでしょ わかりにくくてごめんなさいね この暑さでちょっと疲れてるんだ 282 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:49:09 ] 出来ないことないじゃん。もうInner classあるんだから。 283 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:54:25 ] Inner class って、なんか関係が？ 284 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:59:12 ] インナー・クラスの非仮想化・インライン展開はソース・コンパイル時に出来る。 285 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:21:17 ] --- Outer.java --- public class Outer { class Inner { int foo( ) { return 1; } } void bar( Inner inner ) { System.out.println( inner.foo( ) ); } } インナークラスってこういうのでしょ。 inner.foo( ) をインライン展開するつもり？ --- Main.java --- public class Main { public static void main( String[] args ) { Outer outer = new Outer( ); Outer.Inner inner = outer.new Inner( ) { int foo( ) { return 2; } }; outer.bar( inner ); // → 2 を出力する } } 286 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:42:11 ] そもそもprivate:ならインライン展開し放題じゃない。 287 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:45:06 ] それはまぁね。 288 名前：デフォルトの名無しさん [2007/08/10(金) 17:18:14 ] で、実際デフォルトで（知らないところで）インライン展開はされているのか？ それも、メモリ上に展開なのか、ソースコード（.class）のバイト数が増加しているのか。 289 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:20:42 ] > で、実際デフォルトで （　ﾟдﾟ）ﾎﾟｶｰﾝ 290 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:45:00 ] はいはい、あげあし君はさようならで 291 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:58:23 ] 似たようなことを議論してるよ。 stack allocateについては、 アノテーションで指示するか、 ByteBufferでアドレッシングしてくれってことのようだ。 bugs.sun.com/bugdatabase/view_bug.do?bug_id=4820062 292 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:31:07 ] >>291 そこの議論の対象はC/C++の struct で作られたような データ構造にアクセスする事であって、 言語仕様的に stack allocated object が欲しい場合は bugs.sun.com/bugdatabase/view_bug.do?bug_id=4213096 bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809540 どっちかにvoteしろって書いてあるよ 293 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:35:28 ] C# だと各メンバに FieldOffset が指定できるよね >>291 はそういう話じゃないの？ 294 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:54:29 ] >>292 で、君はそっちのREFをチェックしてからものを言ってるわけなのかな？ >>293 C#がどうしたって？ ざっとみてスタックがどうとか言う議論になってたから似たようなの出してみたのだけど。 295 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 19:02:35 ] いや、データをバイト列にパックする話とスタックアロケーションは別の問題だから。 296 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 03:07:02 ] 君の都合にあわないからといって、いちいち相手にｹﾁをつけるところは君の悪い癖だな

---

---

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

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