976:Name_Not_Found
15/07/13 19:49:41.40 .net
>>954
あなたのいうJSHeapとは何？
- オブジェクトのツリー構造
- ブロトタイプチェーン
- スコープチェーン
- DOMのツリー構造
>>958もいってるけど、オブジェクトとDOMでは親を辿るAPIが違う
そもそも、DOM要素ノードはオブジェクトでもあるわけだから同時に2つのheapが発生することは避けられない
ESにはその他にも様々な参照構造があり、それぞれにheapが存在するものと想像する(実際は知らないけど、上記全てを一つのheapで管理するのはどう考えても現実的じゃない)
>>952の指摘でも感じたけど、あなたは実装面には強いけど仕様に明るい方ではないよね
もう少し、仕様についても勉強した方がいいかと
977:Name_Not_Found
15/07/13 21:25:35.32 .net
まあ全部JSでブラウザを作ろうというプロジェクトもあるし～
最近のモダンブラウザはBlink-in-JS構想とかで徐々にDOMをJS化してきてるし～
今日のことが明日通用しない業界だし～
どうでもいいよね～
978:Name_Not_Found
15/07/13 23:51:58.78 .net
>>958
> また、DOMで子が親を参照するのは当然必要で、parentNodeがまさにそうだ。
だから最初から何度も言っているが、
・子DOM要素が親DOM要素の『スコープ』を保持する必要
・スコープ
・スコープ
・スコープ
子DOMが子DOMのスコープ内に親DOMをもつのはparentNodeが有るからこれは必要。
しかし子DOMが親DOMのスコープを保持する（親DOMから何が見えるかを直接知っている）必要があるのか？ということ。
普通は一旦親DOMを参照した後に、その親DOMのスコープを見ればいい。だから直接もつ必要はない。
しかしMSDNでは、
> 動的に作成された 2 つのオブジェクトどうしを一時的にアタッチして子要素から親要素へのスコープを作成するのが基本的なパターンです。
> 後でこの 2 要素のツリーをプライマリ ツリーにアタッチすると、その両方がドキュメントのスコープを継承し、一時オブジェクトがリークします。
つまり、DOMに親子関係が発生した時にそれぞれスコープを作成して、---(A)
プライマリツリーにアタッチした時にこれらは両方とも変更され、---(B)
結果、(A)がリークすると言っている。
これが起きるのは、
・（A）内部に循環参照がある＝子DOMのスコープと親DOMのスコープに循環参照がある---(α)
・（B）で差し替えられるのは親DOMのスコープのみ＝子DOMが親DOMのスコープを直接保持したままでこれがリーク---(β)
のどちらか。俺は後者だと思っていたからこの質問になっていた。ただ、今から考えれば前者かもしれない。
繰り返しておくが、
○ 子DOMと親DOMに循環参照がある。(parentNode, childNode)
？ 子DOMのスコープと親DOMのスコープに循環参照がある。
？ 子DOMが親DOMのスコープを保持している。
○ 子DOMが子DOMのスコープ内に親DOMを保持している。(parentNode)
これらは全く別物だ。スコープは「スコープオブジェクト」として別に作った方が実装が楽だから、多分そうなっている。
そしてここでリークすると言っているのはその「スコープオブジェクト」であって、「DOMオブジェクト」ではない。
対策は「一時的なアタッチをなくす＝（A）の作成をしない」となっている。
結果的にリークするオブジェクト(A)そのものを作成しないのだから、当然対策できることになる。
979:Name_Not_Found
15/07/13 23:52:34.90 .net
(α）のpatch対策は簡単で、DOMをアタッチする時にそのDOM以下のツリーのスコープオブジェクトを全部GCすればいいだけだ。
ただ、循環参照の対策が出来ているのなら通常のGCで回収できることになるから無駄patchになる。
だから循環参照の対策が根本対策で、こちらを急ぐのが開発方針として妥当で、おそらくこれだろう。
ただ（α）だと書き換えるスコープオブジェクトの数が多く、遅い。
最小限に絞って高速化すると（β）になる。だからこちらを仮定していたのだが、
IEは実際遅いし、循環参照の対策も出来ているのなら、（α）なのかもしれない。
（β）の実装で無理があるともあまり思えないのだが。
もう一度繰り返すと、(>>942)
> ・DOM挿入順が速度最適（ツリーを完成させてから最後に挿入）の場合は今でもリークするのか？
> ・親DOMのスコープを子DOMが保持することが仕様として必要なのか？
俺は後者の仕様はないと思っているし、従って前者も対策されており、リークはないと見ている。
だから、これが間違っていそうなら指摘よろしく。
対象はchromeとFFの共に最新版だけでいい。
980:Name_Not_Found
15/07/13 23:57:19.86 .net
>>958,959
見る限りV8のDOMはおまけだ。ただ、そういう用途があるのかはよく分からない。
ブラウザから離れるのなら、最初からnative(exe)が使える。サーバーサイドは基本的にこれだ。
スクリプトの方が運用が楽だし、スレッド起動できるから今は速いわけだが、
exeをスレッド起動できる仕組みが出来ればスクリプトエンジンは全部抹殺されても不思議ではない。
(DLLの動的『指定』とか)
もちろん速いスクリプトエンジン自体は需要はあるし、JITならさほど遅くもないから、こちらに賭けるという選択だとも見える。
しかしNodeはC->JavaScriptは呼べるが、逆はできない。つまり本体はCで、JavaScriptをブラウザ/WEB用APIとして使う方向だ。
nativeが使える状況で速度至上主義なら、C系以外の選択肢は事実上無い。だからNodeの選択は妥当だ。
もちろんNode自体を動かすためにV8が必要だとしても、若干ここら辺に違和感を感じるのは事実だ。（統一感がない）
そもそも速い共通バイナリならJavaでよかったのだが、chromeはそれも外した。(NPAPIの廃止）
Javaについては他に問題がありすぎるようではあるが。
なお、密結合にはならない。
元々1つの物(DOM)を、2箇所(Blink/V8)から管理するからおかしいことになっている。
見る限りDOMとJSのオブジェクトは相似形だから、同じHeapで同居できるはず。
だから、Blink/V8/JSHeapと分離し、BlinkとV8内部には個別のHeapを持たず、全部JSHeapに突っ込めばいい。
wrapperというコピーが無くなるので、メモリ使用量は減る。
GCはすべてJSHeapに任せられる。単一で内部的にツリーを構成できているから、
「GCされないために云々」という無駄コードを全て捨てられ、プログラムとしては綺麗になる。
ただ、各エンジンとHeapが粗結合になるので、どうしても動作が遅くなる。
(Readはpublic（というか直接ポインタアクセスで動的保護無し）、
Writeはprivateという指定が出来ればいいのだが、これができる言語は多分無い）
だから高速エンジン制作者には不評だろうけど。
とはいえ、Mozillaがやろうとして失敗したようだから、何か他にも問題があるのだとは思う。
981:Name_Not_Found
15/07/13 23:59:43.55 .net
>>960
> あなたのいうJSHeapとは何？
JavaScriptのHeapと書くと長いから、JSHeapと書いているだけ。
ただこの質問は君にはプログラミングセンスがないことを示している。
君には理解不能だろうけど。
> DOM要素ノードはオブジェクトでもあるわけだから同時に2つのheapが発生することは避けられない
何故？そんなことはあり得ない。例えばPCのデータはHDDで全てまかなえている。
やり方次第だ。無理に纏めるのは効率が悪いが、同じ型、同じ物を別々に扱うのはもっと効率が悪い。
localStrageだってkey/value型しかないが、やり方次第でどうとでもなる。そういうものだ。
実際にDOM.jsは動いているんだろ？だったら少なくともJSHeapに突っ込んでもなんとかなるんだよ。
> あなたは実装面には強いけど仕様に明るい方ではないよね
これはその通り。JavaScript歴は半年だからね。
ただそれ以上に君にはプログラマーとしてのスキルがないよね。
> もう少し、仕様についても勉強した方がいいかと
何故？俺はGM使いで、だからJavaScriptを使っているだけだ。
今現在で一通り、やりたいことは書けるようになった。
俺がブラウザを作るのなら仕様を一通り読む必要があるが、その予定はない。
その程度でグダグダ言うなと言うのなら、無視してくれて構わない。
982:Name_Not_Found
15/07/14 00:03:30.93 .net
>>960
君は何のために俺に対してレスを付けているのだ？
俺に対して文句を言いたいだけか？それならいくらでも言えばいいが、無駄だから今後は無視させてもらう。
俺は今、chromeが勝手に落ちる現象に遭遇して困っている。
>>942に書いたとおり、DevToolには現れないが、確かに安定して落ちるので何か原因がある。
だからそれに関する手がかりになりそうな奴にはレスを付ける。
958,959に関しては、俺に対して何かしら情報をくれようとしているのだから、こちらもそれなりに返す。
960に関してはどう返せばこちらの実になるか分からないし、それ以前にどう返して欲しいかも分からない。
仕様を勉強してない奴は黙れというのなら、
仕様を与えられても実装できない君みたいなエセプログラマはもっと黙るべきだ。
仕様は聞けば済む話だが、スキル/センスがないのはここでいくらやりとりしても解決できる話ではない。
君は俺より実装面で弱いという自覚があるようだが、ならば何故その実装面の話に低レベルな横槍を入れるのだ？
質問案件に対し、知っている奴が分かる範囲で気が向いたら答えるのが質問スレの普通のやり方だ。
君のレスは誰のためにも何のためにもならない。
初心者用スレとして維持したいのであれば、俺は「ECMAScriptデス4」に移動してもいい。
俺にレスをくれている奴らの多数決でいい。
> DOM要素ノードはオブジェクトでもあるわけだから同時に2つのheapが発生することは避けられない
Dom.jsでも読めよドアホ。
もう少し、自分が至らないことについて自覚した方がいいかと
983:Name_Not_Found
15/07/14 01:52:01.76 .net
／⌒ヽ
/ ´_ゝ`）すいません、ちょっと通りますよ・・・
| /
| /| |
// | |
Ｕ .Ｕ
984:Name_Not_Found
15/07/14 10:30:45.85 .net
>>962
おそらくページ遷移時のCG順序か機構に問題があって、特定の場合に中間構造がリークするのだろう。
中間構造はドキュメントに接続された際にもう捨てていいはずだが、
JSとの絡みで必ずしも捨てられないケースがあるのか、バグでそうなっていたのだろう。
>>963
今はしない。
>>964
DOMの管理含めて丸ごとJSで組み立てられればラップなんて仕組み必要無いが、
実際にはDOMはレンダリングともつながっているわけで
ブラウザネイティブの世界から大きく切り出すことは出来ない。
985:Name_Not_Found
15/07/14 11:11:23.28 iGbd+ivb.net
URLﾘﾝｸ(blog.jquery.com)
jQuery 3.0 and jQuery Compat 3.0 Alpha Versions Released
jQuery 3.0きた！ アルファだがな。
Major changes
* Simplified .show() and .hide() methods
* Special case with .data() names
* jQuery.Deferred is now Promises/A+ compatible
* Removed special-case Deferred methods in jQuery.ajax
* Error cases don’t silently fail
* .width(), .height(), .css(“width”), and .css(“height”) to return decimal values (whenever the browser does)
* Removed deprecated event aliases
* jQuery.swap, jQuery.buildFragment, and jQuery.domManip are no longer accessible on the jQuery object
* Animations now use requestAnimationFrame
* .unwrap( selector )
* Massive speedups for some jQuery custom selectors
基本的に互換性は保たれているらしい。
個人的にはDeferredがPromises/A+互換になったことが嬉しい
986:Name_Not_Found
15/07/14 11:45:53.25 .net
相変わらずの信者脳だな
987:Name_Not_Found
15/07/14 13:33:39.65 .net
> As an added bonus, both jQuery and jQuery Compat will
> include support for Yandex.Browser, a freeware browser released in 2012.
なんだ？ Yandex.Browserって
988:Name_Not_Found
15/07/14 13:36:04.50 .net
へー
URLﾘﾝｸ(weekly.ascii.jp)
> ロシアの検索市場でグーグルを圧倒するYandex、次にGoogle Playを狙うワケ
URLﾘﾝｸ(www.itmedia.co.jp)
> ロシア検索最大手のYandexが、Chromiumベースでミニマルデザインの
> 新ブラウザ「Yandex.Browser alpha version」をリリースした。
989:Name_Not_Found
15/07/14 16:24:28.23 .net
宣伝うざい
990:Name_Not_Found
15/07/14 16:31:11.58 .net
宣伝をわざわざ貼るくらいこのスレには価値があるということだよ
991:Name_Not_Found
15/07/14 16:37:36.30 .net
別に宣伝じゃなくて、Yandexってなんだ？って思っただけ？
992:Name_Not_Found
15/07/14 17:01:51.96 .net
宣伝云々は荒らしに対してじゃないの
993:Name_Not_Found
15/07/14 17:28:47.88 .net
>>975
ここで質問する必要ないだろ
994:Name_Not_Found
15/07/14 17:35:48.85 .net
俺は別に質問などしてないけど？
995:Name_Not_Found
15/07/14 17:59:13.18 .net
> なんだ？ Yandex.Browserって
996:Name_Not_Found
15/07/14 20:06:29.40 .net
それは俺じゃない
997:Name_Not_Found
15/07/14 20:33:58.02 .net
>>980
>>972だって同じ
ライブラリの話題禁止と書いてあるだろ
998:Name_Not_Found
15/07/14 20:39:10.88 .net
ライブラリの話題じゃないだろｗ
999:Name_Not_Found
15/07/14 20:40:15.07 .net
ブラウザの話題だ
1000:Name_Not_Found
15/07/14 20:43:36.59 .net
>>982-983
ブラウザの話題はもっと関係ないだろ
ブラウザスレでやれ
1001:Name_Not_Found
15/07/14 20:45:43.99 .net
雑談ぐらいいいだろｗ
1002:Name_Not_Found
15/07/14 21:15:40.37 .net
スレ違いの話題に便乗してスレ違いの話題を広げると他の人に迷惑がかかるだろ
常識で考えろ
1003:Name_Not_Found
15/07/14 22:31:18.37 .net
>>968
ブラウザネイティブ＝HTMLレンダラじゃないのか？他の用途は特になさそうだが。
Wikiを見る限り、レンダラとJSエンジンが別なのは歴史的経緯だ。
1998 KDE(KHTML/KJS)
2002 WebKit(WebCore/JavaScriptCore)
2013 Blink(Blink/V8)
切り出すのは出来ないのではなく、今更やるのは大変であり、意味がないからだ。
今ゼロからソースを書くのであれば、
共通のデータストアを用意し、そこに入れさえすれば後は全自動の方が楽だ。
ただ、別Heap方式で実装しきってしまっているようなので、今更切り出す意味はない。
リークに関しては、こちらと同じ見解だということで了解した。ありがとう。
個人的にはMSの技術力は認めているので、何故そんな実装になったかが引っかかるが、
IEはAjax以前からあったから致し方なく、ドキュメントも古いからそんなもんだということにしている。
1004:Name_Not_Found
15/07/14 23:26:32.79 .net
>>987
いいかげんスレ違いの話はやめろ
1005:Name_Not_Found
15/07/15 02:22:48.35 .net
>>987
JSエンジンとレンダラだけについてではなく、
JSエンジンとレンダラ（ブラウザ本体）とDOM管理について話している。
例えばDOMが変更されたら再描画しないといけない。
DOMツリーとレンダリングツリーは密接に繋がっているので、
DOM管理をJS側に持っていくほうが普通に考えると非効率だ。
1006:Name_Not_Found
15/07/15 09:28:12.98 .net
なんかスレチに過敏な方が約一名おられるようで
誰も困らないから多少は見逃せば？
あまりにも続くようだと注意すればいいが何でもかんでも言ってるとスレの雰囲気悪くなる
1007:Name_Not_Found
15/07/15 10:41:13.35 .net
jQueryとlodash以外のスレチは絶対許さない人がいるんだよ
1008:Name_Not_Found
15/07/15 11:22:36.01 .net
アホか、いつjQueryとlodashを認めた？
jQueryとlodashを含めてスレ違いは禁止に決まってるだろ
1009:Name_Not_Found
15/07/15 12:27:16.00 .net
どうでもいい
荒らす気がないのならいい
一度決めたことが未来永劫通用する業界じゃないし
例えばこれからはWASMの範囲だってサポートしていかなきゃならんだろ
1010:Name_Not_Found
15/07/15 12:43:25.99 .net
Web業界の常識とスレのローカルルールの違いも理解出来ない人がいるのね
1011:Name_Not_Found
15/07/15 13:16:00.86 .net
スレチを叩く自治うざい！ じゃあjQueryとlodashを許容しよう！
とはなりませんでした～
1012:Name_Not_Found
15/07/15 13:26:50.02 .net
次スレ誘導
お好きなスレにどうぞ
+ JavaScript の質問用スレッド vol.121 +
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.122 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.123 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.123 +(c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.123 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.124 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.125 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.125 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
1013:Name_Not_Found
15/07/15 13:51:29.57 .net
>>996
乙
1014:Name_Not_Found
15/07/15 22:48:23.38 .net
>>994,995
正直言ってスレのルールなんて関係ない。
1015:Name_Not_Found
15/07/15 23:10:37.85 .net
>>989
多分、そういう議論を繰り返して平行線で今があるのだと思う。
実際、DOMを変更するにしてもHTMLではなくJavaScript側からしかできないだろ？
どっちにも密接なんだよ。
経緯から推測すると、googleはV8でDOMを管理しようとして、これを要求したが、
既にWebCoreで管理していたWebKitからするとウザいだけで、APIの提供で終わった。
googleはこれ以上の高速化にはV8で管理するのが不可欠と見てBlinkにフォークした。
WebKitはV8用のコードをすべて捨てるつもりらしいから、
逆に言えばV8専用のコードがそれなりの量あるということ。
つまりJavaScriptCoreはWebCore内のDOMを直接参照に近い方法で見ていることになる。
Blink： レンダラ+（DOM+V8)
WebKit： (WebCore+DOM)+JavaScriptCore
俺： レンダラ+DOM+JavaScriptエンジン
ということ。どの実装も出来る。上2つは実際にブラウザになっているので、結果は出るだろう。
1016:Name_Not_Found
15/07/15 23:14:37.85 .net
梅
1017:１００１
Over 1000 Thread.net
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
1018:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています