Пользователь
30,2
рейтинг
13 декабря 2011 в 15:17

Разработка → Firefox не вмещается в 32-битное адресное пространство

Разработчики Mozilla столкнулись с проблемой: в процессе компиляции mozilla-inbound под Windows вылетает ошибка (см. баг 709193).

nswindowmediator.cpp(821): fatal error C1001: An internal error has occurred in the compiler. LINK: fatal error LNK1000: Internal error during IMAGE::BuildImage

Проведённое расследование показало, что компоновщик выходит за пределы виртуального адресного пространства во время оптимизации. Ему не хватает 3 ГБ памяти, которые выделяет приложению 32-битная Windows.

Аналогичная проблема возникла перед разработчиками в начале 2010 года, когда компоновщик вышел за пределы 2 ГБ, но тогда проблему удалось решить переходом на лимит 3 ГБ (см. баг 543034), сейчас такого варианта нет.

В качестве временного решения разработчики заморозили добавление функционала в mozilla-inbound и исключили из билда несколько новых модулей: Graphite, libreg и SPDY. Теперь думают, что делать дальше. В такой ситуации есть несколько вариантов: 1) выделить часть кода libxul в отдельные библиотеки; 2) попробовать перейти на MSVC 2010; 3) компилировать 32-битные билды в 64-битной ОС. Проблему сейчас обсуждают на mozilla.dev.platform.

Для передовой версии Firefox — 32-битной версии под Windows, которой пользуются 90% аудитории — используется двухэтапная процедура оптимизации на профилях (Profile-Guided Optimisation, PGO). После первого прохода компилятора составляется профиль работы браузера в реальной среде, после чего осуществляется окончательная компиляция оптимизированной программы. Mozilla перешла на PGO четыре года назад, новый метод улучшил производительность примерно на 10%.
Анатолий Ализар @alizar
карма
749,5
рейтинг 30,2
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (116)

  • +2
    а чем он сейчас собирается?
    • +3
      MSVC 2008, вероятно.
      • +4
        судя по логу — 2005.
        • +1
          а в чём сложность перехода на сборку под 2010?
          • +11
            незаметно могут всплыть баги оптимизатора
          • +28
            100500 ошибок из-за разности компиляторов
          • +4
            Однажды перешли на 2010 на середине проекта. После месяца исправления багов очень радовались, что можем вернуться к работе по проекту без еженедельных сказок и оправданий перед заказчиком.
            • 0
              А какого типа и насколько крупный проект?
              • 0
                Интеграция нескольких систем, для чего пытались использовать сначала стандартные очереди, потом самописные реализации очереди. Также постигло большое разочарование с мылом, в результате чего мыльная часть была частично написана без библиотек типа net.mail, а частично с ними. Вобщем-то использовали, если ничего не перепутал, только smtp отсылку из этой библиотеки, остальное самостоятельно реализовавали, и долго правили из-за этого.
                • 0
                  А почему не допилили существующие решения?
                  • 0
                    Именно что допилили, но это заняло время.
  • –23
    Лет через 10-20 для тех-же операций не будет хватать миллионов терабайт памяти.
    • +22
      > миллионов терабайт
      эксабайтов
      • +1
        тысяча тысяч тысяч тысяч тысяч тысяч байт!
        • +21
          Тысяча двадцать четыре тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх байтов.
          • –4
            Вообще-то не совсем правильно, т.к. Гигабайт это 10^9 байт, а не 2^30.
            Ну и все последующие после гигабайта это степени основания 10, а не основания 2.

            Хотя та же википедия говорит о разночтении начиная с мегабайта.
            В сущности это всего-лишь несоответсвите терминологии ГОСТа, по которым производят и маркируют накопители. Единицы измерения информации
            • +1
              Оперативная память измеряется в степенях двойки.
              • 0
                Именно потому эксабайт неравен тому, что вы написали.
                • –3
                  Пичалька.
            • 0
              В этом самом ГОСТе 8.417-2002 написано следующее: «Исторически сложилась такая ситуация, что с наименованием „байт“ некорректно… использовали (и используют) приставки СИ: 1 Кбайт = 1024 байт, 1 Мбайт = 1024 Кбайт, 1 Гбайт = 1024 Мбайт и т.д. При этом обозначение Кбайт начинают с прописной буквы в отличие от строчной буквы „к“ для обозначения множителя 10^3». Хотя да, особые педанты могут продолжать настаивать на мебибайтах, гибибайтах и прочих причудливых словах.
              • 0
                Как бы то ни было, Мегабайт не равен Мбайту. Тут или математика или слэнг, выбирайте сами.
  • +38
    Надо же было столько понаписать…
    • +2
      Это не обязательно написанный руками код. Что-то может генерироваться автоматически, что-то — результат инстанцирования шаблонов в C++.
  • +3
    прямо как компиляция сетевых библиотек буста (Boost) там влегкую за пределы памяти можно выйти на 32 битах)))
  • +8
    В современных браузерах строк исходного кода больше, чем в ядрах современных ОС…
    • +64
      Современные браузеры стремительно становятся современными ОС.
      • +5
        Возникает вполне закономерный встречный вопрос: а к чему же тогда стремятся современные ОС? :)
        • +6
          Интеграции с браузерами, для обеспечения максимально комфортного симбиоза?)
          • 0
            Похоже скоро стоит ждать первенца как результат этого симбиоза )
            • +6
              chromium os?
              • 0
                И действительно, правда есть мнение что он какой-то недоношенный получился.
                • 0
                  Я ставил, да сыроват, а если запускать не с харда, а с флэшки, так еще и тормозит ужасно. Как говорят, первый блин комом.
          • +5
            Кто-то на Микрософт за это в свое время в суд подавал. А они оказывается все заранее предвидили!
        • 0
          к BIOS'у
        • +6
          К квадратикам
        • +1
          К любви и гармонии
  • +1
    А что не так с переходом на х64 платформу?
    • –1
      Нарвеное чтобы проверить скомпиленное нужно будет переходить в 32-битную ОС.
      • 0
        Я думаю в мозилле не дураки сидят, и у них в виртуалках целый зоопарк ОС.

        Правда с Mozilla 3.0 у них вышел былинный отказ. Самая первая 3.0 версия не хотела стартовать на Win7 x64.
    • +2
      даже у x64 msvc линкер 32х битный. а проблема как раз в нем
      • 0
        Судя по одному из предложенных вариантов «перейти на MSVS 2010» — там линкер уже 64х битный?
        • 0
          Нет, просто он чуть бережнее обращается с памятью.
      • +1
        Во первых линкер есть и такой и такой. Во вторых, они уперлись в предел 3Гб адресного пространства, а wow64 процессам (32-битные процессы на 64-битной системе) отдаются вообще все 4Гб адресного пространства (если бинарник говорит о том, что он согласен с тем, что старший бит в указателях может быть ненулевым — а link.exe имеет поддержку больших адресных пространств испокон веков — собственно это тот же флаг, который включает поддерку /3GB для процесса). В общем на полгодика б хватило — а там все равно весь девелопмент переводить на x64. Хоть так хоть эдак. Ну или отключать PGO
        • 0
          Нет, эт все понятно — не хотят переводить билдеры на x64 и там кросс-компилить. Но как тогда быть с этим утверждением? Или оно ошибочно?

          >> Microsoft is not going to provide us with a 64-bit linker in any reasonable timeframe. We cannot switch wholesale to any other linker because we need the optimizations (including PGO) in Microsoft's.

          Так и так линкер упрется в 4Гб адресного пр-ва на PGO.
          • +1
            Это откуда цитатка (интересно посмотреть на уровень неадеквата)?
            Вот это из VS2010 (есть подозрения, что и в более старых версиях все так же, но проверить мне сейчас негде — старых версий нигде не осталось)


            Ну и на всякий случай, вот так выглядят загруженный в этот процесс модули:

            • +1
              Так дело в кросскомпиляторе. Им все равно, нужно собирать бинарники для x86, но с помощью линкера и компилятора, которые сами работают на x64. (Кстати, линкер вызывает компилятор для некоторых задач в режиме PGO, так что нужны обе вещи). Microsoft сейчас такую возможность не предоставляет.
              • 0
                Да, я действительно не подумал, что для LTCG нужен бекэнд компилятора, а для генерации x86 кода он есть только в x86 варианте. Ну в таком случае им нужно серьезно подумать о рефакторинге одного монолитного бинарника в несколько более меликих.

                Ну или попрофайлить и выяснить где получается наибольший выигрыш от PGO (наиболее «горячие» участки кода) и оптимизировать только эти места, а не все подряд.
            • 0
              Прошу прощения за оффтоп, но что это за программа, скрин которой был представлен?
              • 0
                Это Process Hacker. По большей части дублирует функционал Process Explorer Руссиновича, но в некоторых вещах превосходит его.
          • 0
            > Так и так линкер упрется в 4Гб адресного пр-ва на PGO.
            Пока что он уперся в 3Гб, а в прошлый раз (начало 2010) — в 2Гб. Так что один дополнительный гиг доступных адресов дал бы им возможность оставаться в прошлом еще год-два.
            • 0
              Спасибо)
  • +112
    А я рад что и разработчики тоже испытывают сложности связанные с потреблением памяти их поделки.
    • +2
      А какая связь с потреблением памяти самим firefox???
      • +4
        и тот и тот едят много памяти
      • –5
        Это почти синонимы, к сожалению, но слышал что ведется работа в этом направлении, и осчастливить нас хотят уже через несколько месяцев (в 10й версии вроде как).
      • +6
        Ну клевая же шутка.
    • +7
      Как связаны потребление памяти линкером при использовании PGO и потребление памяти самим Firefox?
      • +2
        Это что-то вроде метафоры.
    • +19
      Отвечаю всем, связь такая что это рыжее чучело, после для работы (все вкладки закрыты), может кушать 1.5 Гб. Так вот, я рад что у разработчиков лисы тоже есть проблемы с памятью, мне пофиг какого они характера проблемы, но так они лучше поймут пользователей.

      PS все равно его люблю )
      • 0
        … дня работы…
      • +4
        Разработчики выкрутятся, Вы даже не сомневайтесь — и тот метод, которым они выкрутятся (будет ли это разбивка на модули или компиляция под х64) нифига не поможет конечному пользователю с его проблемами потребления памяти браузером.
        • –1
          Конечно выкрутятся, на то мы и разработчики :)
        • –1
          Просто сам факт того что им придется выкручиваться доставляет. Даже вспоминается недавняя проблема с госдолгом США, отложат еще раз (не проведут глубокий рефакторинг), всплывет снова через годик.
      • 0
        UpTime рыжего чучела 8 версии порядка полутора недель, открыто в среднем около 20 вкладок в трёх группах вкладок, кушает 400 метров с фаербагом и адблоком, может проблема не в самом чучеле-то?
        • +1
          Используете ли вы в разработке что-то подобное ExtJS, например? :)
          • 0
            Нет, я бэкэндщик по большей части, а что там с ExtJS? Из-за него хромает только лиса?
            • +1
              firebug при активной работе с ExtJS показывает чудеса текучести памяти. того и гляди сам firebug за пределы памяти вылезет)
              • 0
                Ну вот, один серьёзный и огненный баг в огненной лисе нашёлся, осталось быстренько пофиксать его! :)
              • 0
                А если добавить сюда Illuminations, то становится все чудесатие и чудесатие. Хотя, если честно, в последее время лиса ведет себя лучше. :)
              • +1
                Так может всё-таки firebug течёт, а не firefox?
                • +1
                  Проверено, однозначно firebug. Но они тоже вроде исправляются. Совсем недавно научились очищать память при обновлении страницы, уже вперед.
        • +1
          Зайдите на сайт с детскими играми — как делает каждый день мой трёхлетний сын — и будет гигабайт минимум. Вроде всего-то простенькая аппликация, а память летит только так.
          • +1
            Игры же на Flash скорее всего?
            • 0
              да, но памяти тем более течь не должно.
              • +1
                Как будто во флеше не может быть утечек, особенно если писано индусами.
                • 0
                  Мне казалось, что после закрытия странички с флэшем утечка памяти, вызванная флэш плагином, должна пропадать. Не пропадает же. Значит не индусы виноваты, как Вы думаете?
                  • 0
                    about:memory посмотрите сначала. И сколько ест plugin-container в процессах. Если вы флешку закрыли — это не значит, что там по волшебству вся память осободилась.
                    • –1
                      Если вы флешку закрыли — это не значит, что там по волшебству вся память осободилась.
                      А куда же она девается-то, если не освободилась? Зачем лиса её держит, как сыр?
                      • +1
                        Всё что угодно может быть. Начиная сборщиком мусора (который и у флеша тоже есть) и заканчивая невозможностью освободить участок памяти (хотя последнее скорее выдаст run-time error).
                        • 0
                          Учитывая, что FireFox ориентируется на плагины сторонних разработчиков, он должен сам следить за тем, чтобы эти плагины хотя бы после прекращения работы не потребляли память. Раз не следит — это вина разработчиков FireFox. Тут можно спорить только если поставить целью во что бы то ни стало продвигать тезис о непогрешимости FireFox.
                          • 0
                            Смеётесь что ли? Это как если бы вы просили Microsoft следить за всеми программами сторонних разработчиков для Windows.
                            • +2
                              Я Вас сейчас насмешу: Микрософт это и делает. И это делает любая операционная система, это её профильное занятие. Программа запустилась, нагадила в отведённой ей памяти, закончила работу — память вернулась в систему.
      • 0
        Рыжее чучело Iceweasel 3.6.24, полсотни вкладок, четыреста мегабайт. Временами доползает до пятисот-шестисот. Аптаймы многодневные, а то и многонедельные.
      • +1
        У меня хром с ~20-25 вкладками ноут с 6 гигами памяти в своп уводит иногда :(
        Так что далеко не только у лисы проблемы.
    • +1
      Да ладно бы, пусть кушает хоть два гигабайта, но пусть не тормозит «за эту цену»!
      Тормоза Firefox вымораживают гораздо больше, чем потребление памяти.
      • 0
        А может тормоза следствие того что его разжиревшее пузо по земле таскается )
  • –19
    Не хочется разводить холивар, Firefox отличный браузер, и навсегда останется в памяти, но лично мне больше по душе Chrome, и основной причиной перехода (причем почему-то довольно сложного для меня было), это именно из-за того, что он на маке сильно долго грузился (да и не только на маке).
    • +17
      При чем тут вообще Chrome и Mac, когда речь идет о проблемах компиляции?
    • +75
      >Firefox отличный браузер, и навсегда останется в памяти

      Звучит угрожающе.
      • –7
        Не хочу показаться «хромоебом», но вроде как по последним данным он сдает позиции Chrome, да и если Google откажет Firefox-у в материальной поддержке, тоже не сильно весело будет для Mozilla Foundation.

        Хотя если вы имеете ввиду что он на текущий момент зависает в памяти надолго, то тогда да — звучит более угрожающе, грозит перезагрузкой. :)
      • +5
        Звучит похоже на сообщение Windows ;-)
      • 0
        новая услуга: очистка памяти от сторонних программ.
    • +22
      > навсегда останется в памяти

      Если памяти хватит =)

      (извините не удержался)
  • 0
    Может я чего-то не понимаю, но по-моему самый идеальный вариант на сегодняшний день — разбить части кода на библиотеки. Это и оптимальней, и время компиляции сократится (не придётся компилировать лишний раз то, что уже скомпилировано), и отладка проще.
  • 0
    image
    • +87
      Сорри, гуглоплюс не отдал картинку :(
      • +7
        Похоже на волка из мультика:
        — Сы-па-сы-ба… Ну ты заходи, если шо!..
      • +8
        собрала операционка все браузеры и говорит: — того, кто будет безмерно жрать память — буду бить по наглой рыжей морде. (с)
  • +10
    «Firefox не вмещается в 32-битное адресное пространство»
    Может всё-таки, компилятор Firefox не вмещается? У самого продукта с памятью пока запас есть.
    Да и (3) решение выглядит слишком очевидным. В-общем, моё субъективное мнение: проблема не стоит даже того, чтобы в баг-лист добавлять.
    • +12
      Вы забыли про автора топика
      • +1
        Мне кажется, или в каждом посте вышеозначенного автора есть такой коммент? :)
  • 0
    PAE и серверная версия виндовса для компиляции?
    Вобще, у проблемы масса решений, и она скорее не является чем-либо серезным, а просто забавным случаем.
    • +7
      PAE позволяет всей системе адресовать больше физической памяти. Процессу будет выделяться всё равно такое же количество виртуальной памяти.
      • 0
        По большому счету да, хотя, насколько мне известно существуют хаки. А википедия вот говорит, что с PAE процессу выделяется 4 гигабайта.
        • 0
          С PAE в одном процессе можно адресовать 4 гигабайта, как и везде на 32-битных процах x86.
          Вопрос только в том, что гигабайт зарезервирован под нужды системы.
          • 0
            Спасибо, понятно.
  • +22
    Заголовки ализара не вмещаются в здравый смысл.
  • 0
    Вот то что SPDY выпилили это фигово. Интересно было бы повозиться
  • 0
    растолстел окончательно.
  • +1
    Сенсация!
  • +40
    Не вмещается линковщик, а не сам Firefox, расходимся!
    • 0
      Посмотрите на имя автора статьи. Потом на заголовок. Дальнейшие комментарии излишни.
  • 0
    А почему 3 ГБ в Win32? Я бы сказал 4 (2^32) минус выделенное пространство под устройства, ресурсы етц.
    • 0
      Потому что /3gb
    • 0
      А ядру в каком пространстве работать? Будешь урезать память для ядра — проиграешь в производительности.
  • 0
    Кто будет жрать дофига оперативы, получит по наглой рыжей морде.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.