パスワードを忘れた？ アカウント作成
Close
1048569 story
Firefox

Firefox、バイナリサイズが大きくなりすぎて 32 ビット Windows では最適化ビルドできなくなる 91

ストーリー by reo
山椒魚 部門より

ある Anonymous Coward 曰く、

最近活発なリリースが行われている Firefox であるが、バイナリのサイズが大きくなりすぎたため、32 ビット Windows ではリンク時のガイド付き最適化 (PGO) がメモリ不足で実行できなくなっているそうだ (mozilla.dev.platform グループへの投稿、本家 /. 記事より) 。

32 ビット版 Windows は最大 3 GB までしかメモリを利用できないが、PGO ではこれ以上のメモリが必要になってしまったそうだ。いまのところは inbound ブランチだけの問題で「64 ビット版 Windows でビルドする」などいくつかの解決策が提案されている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Firefox、バイナリサイズが大きくなりすぎて 32 ビット Windows では最適化ビルドできなくなる More

  • 十分なメモリを扱えるリンカだと、対応バイナリを吐けないから。

  • リンカーだけでなく (スコア:2)

    by ef (25263) on 2011年12月16日 20時23分 (#2067517)

    MicrosoftのPGOはリンカーだけでなく
    /O1と/O2で適用される最適化項目の多くにフィードバックされたと思います。
    （メモリ不足には、中間 COMDAT の除去も影響しそう）

    あと、SeaMonでは8月頃から既にメモリ不足が出ていた様です。
    http://srad.jp/journal/537189 [srad.jp]

  • Windows32bitAPIだとラージページが使いにくいのは確かだけど

    • Re:PAEとラージページ使わないのか (スコア:1)

      by Anonymous Coward on 2011年12月16日 13時03分 (#2067279)

      ・足りないのは物理メモリではなく仮想アドレス空間です。ラージページで物理メモリを節約できても関係ありません。
      ・足りないのは実行時の(firefox.exeの)メモリではなくビルド時の(link.exeの)メモリです。改修できるのはMicrosoftだけです。

      シェア
      親コメント
      • らじゃった。先に問題に直面していそうなWindowsとかOfficeとかIEのリンクをMicrosoftはどうやって解決しているんだろう。
        シェア
        親コメント

        • M$の開発体制 (スコア:1)

          by BIWYFI (11941) on 2011年12月16日 16時18分 (#2067405) 日記

          旧版Windowsでの動作を捨てて、最新のVisualStudioを使うと問題は生じない。
          だから、新機能は新OSでしか提供されないのさ。

          --
          -- Buy It When You Found It --
          シェア
          親コメント

        • Re: (スコア:0)

          by Anonymous Coward

          DLLとして分かれている部分が多いから問題となってないとかですかね

        • Re: (スコア:0)

          by Anonymous Coward

          >「64 ビット版 Windows でビルドする」などいくつかの解決策が提案されている。

          この提案はWindowsにもそのまま適用できそうだけど。
          あと、Microsoftの製品はdllの集合体みたいなイメージがある。

      • Re: (スコア:0)

        by Anonymous Coward

        あ、ラージページでカーネルがページテーブルに予約しているアドレス空間も節約できるかもしれませんが、足りないのはユーザー空間なのでどのみち関係ありません。

      • Re: (スコア:0)

        by Anonymous Coward

        え？
        MSなら改修できるの？

      • Re: (スコア:0)

        by Anonymous Coward

        なんでもマイクロソフトのせいとかギャグですか！
        改修できるのはインテルじゃないの？
        改修してできたのがx64アーキテクチャじゃないの？

        • Linuxは32ビットでも3GBの壁突破できたはず。
          例えばUbuntuはPAE有効版あります。

          ＃コレでFireFoxのコンパイルできるのかどうかは知らない。

          シェア
          親コメント

          • Re: (スコア:0)

            by Anonymous Coward
            PAE 有効にしても 1 プロセスで使えるメモリ空間(4GiB, 事実上は2-3GiB)は変わらないから結局同じなんじゃないかなあ

        • Re: (スコア:0)

          by Anonymous Coward

          link.exeをIntelが作っているとは知りませんでした。
          まともな64bitのlink.exeがないのも、AWEを使ったりメモリがなくなるとファイルにスワップする等して何とか続行したりしないでInternal Errorを吐いてlink.exeがコケるのもIntelのせいだったんですね。

  • VC 2010? (スコア:1)

    by tamago-chi (42926) on 2011年12月16日 15時03分 (#2067373) ホームページ

    1) Make libxul smaller - Either by removing code entirely or by splitting
    things into separate shared libraries.
    2) Move to MSVC 2010 - We know that changesets that reliably failed to link
    on MSVC 2005 linked successfully with MSVC 2010. What we don't know is how
    much this helps (I expect the answer is somewhere between a lot and a
    little). We can't really do this for (at the bare minimum) a couple more
    weeks anyways due to product considerations about what OSs we support.
    3) Do our 32 bit builds on machines running a 64 bit OS. This will allow
    the linker to use 4 GB of address space.

    と2番目にVC 2010対応させることが書いてあるけど、2010にするとメモリ消費が抑えられたという何か実例があるのかな？

  • 単にプログラムの多くの部分を外部のDLLファイルに分割すればいいのではないかな、と。
    共有ライブラリとしてDLLを使用する訳ではないので、DLL Hellのような問題は生じません。

    当然、この場合全体的なプログラムの肥大化は止まりません。

  • L80.COM (遠い目) (スコア:1)

    by oku (4610) on 2011年12月17日 9時36分 (#2067673) 日記

    昔の CP/M とか MSX-DOS な L80.COM みたいなことで未だに悩まされるんですね... オンメモリでリンクするリンカは Microsoft の習い性なのかしらん？ (確かに実装は楽だと思うけど)。

  • 死滅へさらに加速する (スコア:0, 荒らし)

    by Anonymous Coward on 2011年12月16日 13時02分 (#2067278)

    肥大化恐竜化で死滅へさらに加速するFirefox。
    ググるの支援も打ち切られて狂暴度はさらにアップ。
    一体今はバージョンいくつ？42000.10.12？

    そろそろネスケと同じ末路を辿るのが見えて、
    何とも皮肉が効いている。

    • Re:死滅へさらに加速する (スコア:1)

      by Anonymous Coward on 2011年12月16日 13時11分 (#2067287)

      Firefox 8.0.1のxul.dll 15,419KB
      Chrome 16.0.912.63のchrome.dll 28,128KB
      ごく簡単に確認できる基本的な事実くらいは調べてから発言したほうが恥をかかずに済みますよ。
      # で、Chromeはどうやって倍近い大きさのバイナリをビルドしてるんだろう。

      シェア
      親コメント

      • Re:死滅へさらに加速する (スコア:2, 参考になる)

        by Anonymous Coward on 2011年12月16日 13時44分 (#2067322)

        Chromeは64bit Windowsでビルドしている [pcworld.com]そうです。

        シェア
        親コメント

      • Re: (スコア:0)

        by Anonymous Coward

        ＞Chromeはどうやって

        専用の特殊サーバ数百台で分散ビルドしている、とかかも知れない

        • Re: (スコア:0)

          by Anonymous Coward

          PGOって分散ビルドすると1プロセスあたりの使用メモリ量を減らせるようになってるんですか?

          • Re: (スコア:0)

            by Anonymous Coward

            いやいやいや、専用特殊サーバってのは、コンパイラやリンカはもちろん、OSもハードも
            Googleの独自開発、というボケにそのツッコミは勘弁してください('A`)

    • Re: (スコア:0)

      by Anonymous Coward
      日記にでも書いてろ。

    • Re: (スコア:0)

      by Anonymous Coward

      でもChrome（Chromium）というかWebkitの方が肥大化という意味では先行しているの。

  • そろそろ名前変える時期かな (スコア:0)

    by Anonymous Coward on 2011年12月16日 13時08分 (#2067285)

    ネスケ→Mozilla→Firebird→Firefoxとずっと使ってきたけど
    肥大化したから名前変えて再出発の歴史だったような気がするから
    Firefoxもそろそろそんな時期に来たんだろうか
    つかFirefoxも4以降肥大化が加速してる感じだし

    • Re:そろそろ名前変える時期かな (スコア:1)

      by Anonymous Coward on 2011年12月16日 13時28分 (#2067308)

      ＞肥大化したから名前変えて再出発の歴史だったような気がするから

      バイナリサイズやコードの肥大化が原因での名称変更はMozilla→Phoenixだけでしょう。その後は

      Phonenix（BIOSメーカと衝突）→Firebird（データベース名称と衝突）→Firefox

      という具合に、ほとんど商標の問題だと思います。

      シェア
      親コメント

      • Re: (スコア:0)

        by Anonymous Coward

        Firebirdについては法的な問題ではなかったんだけど、異議申し立てに応じた感じでしたね。
        そういいつつ、Firefoxもイギリスで衝突していて、合法的な解決をしたはずです。

  • 64bit (スコア:0)

    by Anonymous Coward on 2011年12月16日 14時00分 (#2067331)

    FirefoxもThunderbirdも64bit版を標準とするにはまだ早いんでしょうか

    • Re: (スコア:0)

      by Anonymous Coward

      そうすると16bitアプリケーションが動かなくなって業務が停止します（それは俺の責任じゃないからサボれて嬉しいな～）

typodupeerror

アレゲは一日にしてならず -- アレゲ見習い