アカウント名:
パスワード:
malloc/freeの処理コストってどれくらいかかるんだろう。メモリがバカ高かった時代はmalloc/freeで使用量を厳密に、というのはわかるんだが、ンGB当たり前の昨今、malloc/freeの処理コストの方が高くなったりしないのかな？と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
・・・malloc/free叩いとらんな、最近。
＞malloc/freeの処理コストの方が高くなったりしないのかな？＞と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
チマチマ何回かに分けて取るより一回にまとめて取った方が相対的に安くなるので、「だいたい、このくらい」でまとめて取ってから、それをアプリ内部でチマチマ切り刻んで使うというテクニックは昔からあったと思います。
そしてJVMなんかだと、それを自動でやってくれるので、Javaな人にとってはこれも「もうやらなくていい昔のコーディングテクニック」の一つですね。
それから、OSが仮想記憶をサポートして以降は、mallocは実メモリを確保するわけではなくOSの管理テーブルに予約するだけなので、ちょっとくらい大きい領域を予約しても影響はすごく小さくなってるはずです。
>そうか、Javaだと（よほど変なことをしない限り）メモリリーク心配しなくていいのか（本当？）
いえいえ、お馬鹿なコードを書くとリークしていきますよ。使わなくなったオブジェクトに対する参照をつかんだままにしてればいくらでもメモリ使用量は増えていきますから。
スコープを外れた変数のつかんでるオブジェクトの回収とかは勝手にやってくれますが変数参照が生き残っていれば回収できないのです。プログラムグローバルなキャッシュを何も考えずに書かせると、そんなコードができるんじゃないですかね。ただ、まぁ、そうはいってもCに比べれば格段に問題のあるコードは書きにくくなっているでしょうね。
＞>そうか、Javaだと（よほど変なことをしない限り）メモリリーク心配しなくていいのか（本当？）＞いえいえ、お馬鹿なコードを書くとリークしていきますよ。
「メモリリーク」という単語を、「ポインタ（或いは参照）を全て手放したにもかかわらず、領域の解放(free)を 忘れたために、メモリを少しずつ食い尽くしていく現象」と定義するなら、Javaだと「メモリリーク」の心配はほぼありません。＃まさに「よほど変なことをしない限り」、且つ「VMやフレームワークにバグがない限り」。＃C言語で長期間動作するアプリを作るのが難しいのは、このような「狭義の＃メモリリーク」の検
>＃まさに「よほど変なことをしない限り」、且つ「VMやフレームワークにバグがない限り」。>＃C言語で長期間動作するアプリを作るのが難しいのは、このような「狭義の>＃メモリリーク」の検出とデバッグが難しいからで、Javaではそれが発生しない>＃ことがサーバー向けアプリに適している理由でもあります。
これ、素直に初耳なんですけど。。サーバ向けアプリで知っているとすれば、銀行勘定系（COBOL）のフロントUI位なんですが、そんなに、サーバー向けアプリ＋Javaって多い！？また、開発言語の選択基準がメモリの確保/解放が決め手になるなんて、どんだけ幼稚なんだと
これ、素直に初耳なんですけど。。サーバ向けアプリで知っているとすれば、銀行勘定系（COBOL）のフロントUI位なんですが、そんなに、サーバー向けアプリ＋Javaって多い！？
一時期、DBを叩くWEBアプリをTomcatのようなJavaフレームワークで構築するのが流行りましたよ。今時はマシンパワーが上がったのでPerlやPHPやRubyを使うようになりましたけど。
また、開発言語の選択基準がメモリの確保/解放が決め手になるなんて、どんだけ幼稚なんだと。。＜確かにそんな話する、トンでも外注（害虫！？）もいることにはいるけどなぁ。。
既出っぽいですけどメモリアロケーションの実体が言語インタプリタにあると言うのはメンテナンスの面からはやりやすいのですが。コンパイラでネイティブコードにした物を動かした場合のこの手のバグ潰しのややこしさを考えると…
まぁ、純粋にCだけで書いて必要なメモリは必ずmalloc噛ます。構造体すら一度mallocして割り当ててしまう。とかそういう非常に神経質にやる場合は例外として、下手なC++コンパイラとかみたくオブジェクトバンバン作って後で変な残りカスが出てしまうというのはどこにバグの責任所在があるか見極めるのが非常に難しい。特に多くのプロセスが立ち上がったり消えたりを繰り返す場合には見えないメモリリークの蓄積で仮想記憶領域を食いつぶし、マシン飛ばしたり速度落としたりとか普通にありますよ。# MPU自体が完璧に近いガベージコレクション機能を持てばC++も信頼出来るようになるのですが、# 今はOSカーネルのGC機能とコンパイラの正確さ頼みだからな…
動的メモリを確保できる言語は、メモリリークの問題を常に持っている。この位の事を理解していないと、言語の種類なんか関係なくロクなコードなんか書けないと思けど。
このあたりは[全体｜詳細]設計とか誰にどこのコーディング振るかというプロジェクトマネージメントとかの問題でコーディングに入る前に理詰めで潰せていないとどうしょうもないですよ。それでもコーディングに入ったら最初はリークバリバリになりがちで、それが書き方の問題か組み合わせの問題か容易に見分けられる準備していないと。一つ一つのルーチンがメモリリーク潰せていても、組み合わせた場合にどうかというのはまた違う。設計段階でメモリリーク誘発しにくいように見極めが出来ていないとダメなのでは。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
時々思うんだが (スコア:3, 興味深い)
malloc/freeの処理コストってどれくらいかかるんだろう。メモリがバカ高かった時代はmalloc/freeで使用量を厳密に、というのはわかるんだが、ンGB当たり前の昨今、malloc/freeの処理コストの方が高くなったりしないのかな？と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
・・・malloc/free叩いとらんな、最近。
-- gonta --
"May Macintosh be with you"
Re: (スコア:2, 興味深い)
＞malloc/freeの処理コストの方が高くなったりしないのかな？
＞と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
チマチマ何回かに分けて取るより一回にまとめて取った方が相対的に安くなる
ので、「だいたい、このくらい」でまとめて取ってから、それをアプリ内部で
チマチマ切り刻んで使うというテクニックは昔からあったと思います。
そしてJVMなんかだと、それを自動でやってくれるので、Javaな人にとっては
これも「もうやらなくていい昔のコーディングテクニック」の一つですね。
それから、OSが仮想記憶をサポートして以降は、mallocは実メモリを確保する
わけではなくOSの管理テーブルに予約するだけなので、ちょっとくらい大きい
領域を予約しても影響はすごく小さくなってるはずです。
Re: (スコア:0)
そうか、Javaだと（よほど変なことをしない限り）メモリリーク心配しなくていいのか（本当？）でも起動時に1GByte以上のヒープサイズが必要ですとかいわれると、いくらメモリ安くなったとっていってもすこしひくなぁ。
Re: (スコア:1)
>そうか、Javaだと（よほど変なことをしない限り）メモリリーク心配しなくていいのか（本当？）
いえいえ、お馬鹿なコードを書くとリークしていきますよ。
使わなくなったオブジェクトに対する参照をつかんだままにしてれば
いくらでもメモリ使用量は増えていきますから。
スコープを外れた変数のつかんでるオブジェクトの回収とかは勝手にやってくれますが
変数参照が生き残っていれば回収できないのです。
プログラムグローバルなキャッシュを何も考えずに書かせると、そんなコードができるんじゃないですかね。
ただ、まぁ、そうはいってもCに比べれば格段に問題のあるコードは書きにくくなっているでしょうね。
Re: (スコア:2, 参考になる)
＞>そうか、Javaだと（よほど変なことをしない限り）メモリリーク心配しなくていいのか（本当？）
＞いえいえ、お馬鹿なコードを書くとリークしていきますよ。
「メモリリーク」という単語を、
「ポインタ（或いは参照）を全て手放したにもかかわらず、領域の解放(free)を
忘れたために、メモリを少しずつ食い尽くしていく現象」
と定義するなら、Javaだと「メモリリーク」の心配はほぼありません。
＃まさに「よほど変なことをしない限り」、且つ「VMやフレームワークにバグがない限り」。
＃C言語で長期間動作するアプリを作るのが難しいのは、このような「狭義の
＃メモリリーク」の検
Re: (スコア:0)
>＃まさに「よほど変なことをしない限り」、且つ「VMやフレームワークにバグがない限り」。
>＃C言語で長期間動作するアプリを作るのが難しいのは、このような「狭義の
>＃メモリリーク」の検出とデバッグが難しいからで、Javaではそれが発生しない
>＃ことがサーバー向けアプリに適している理由でもあります。
これ、素直に初耳なんですけど。。
サーバ向けアプリで知っているとすれば、銀行勘定系（COBOL）のフロントUI位なんですが、
そんなに、サーバー向けアプリ＋Javaって多い！？
また、開発言語の選択基準がメモリの確保/解放が決め手になるなんて、どんだけ幼稚なんだと
設計者の問題（Re:時々思うんだが (スコア:1)
一時期、DBを叩くWEBアプリをTomcatのようなJavaフレームワークで構築するのが流行りましたよ。
今時はマシンパワーが上がったのでPerlやPHPやRubyを使うようになりましたけど。
既出っぽいですけどメモリアロケーションの実体が言語インタプリタにあると言うのはメンテナンスの面からはやりやすいのですが。コンパイラでネイティブコードにした物を動かした場合のこの手のバグ潰しのややこしさを考えると…
まぁ、純粋にCだけで書いて必要なメモリは必ずmalloc噛ます。構造体すら一度mallocして割り当ててしまう。とかそういう非常に神経質にやる場合は例外として、下手なC++コンパイラとかみたくオブジェクトバンバン作って後で変な残りカスが出てしまうというのはどこにバグの責任所在があるか見極めるのが非常に難しい。
特に多くのプロセスが立ち上がったり消えたりを繰り返す場合には見えないメモリリークの蓄積で仮想記憶領域を食いつぶし、マシン飛ばしたり速度落としたりとか普通にありますよ。
# MPU自体が完璧に近いガベージコレクション機能を持てばC++も信頼出来るようになるのですが、
# 今はOSカーネルのGC機能とコンパイラの正確さ頼みだからな…
このあたりは[全体｜詳細]設計とか誰にどこのコーディング振るかというプロジェクトマネージメントとかの問題でコーディングに入る前に理詰めで潰せていないとどうしょうもないですよ。それでもコーディングに入ったら最初はリークバリバリになりがちで、それが書き方の問題か組み合わせの問題か容易に見分けられる準備していないと。
一つ一つのルーチンがメモリリーク潰せていても、組み合わせた場合にどうかというのはまた違う。
設計段階でメモリリーク誘発しにくいように見極めが出来ていないとダメなのでは。
Re: (スコア:0)
具体的に、どんなOSで?
WindowsやLinuxでは、mallocやnewしたものをfree、deleteし漏らしてメモリリークしても、プロセスが終了したときには、当該のプロセスがプライベートに確保したメモリはすべて開放されますよ。