alizar Dec 13 2011 at 15:17

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

1 min

3.3K

Firefox

+59

116

Comments 116

u_story Dec 13 2011 at 15:42

а чем он сейчас собирается?

JhaoDa Dec 13 2011 at 15:44

MSVC 2008, вероятно.

mark_ablov Dec 13 2011 at 15:54

судя по логу — 2005.

u_story Dec 13 2011 at 16:16

а в чём сложность перехода на сборку под 2010?

zone19 Dec 13 2011 at 16:36

незаметно могут всплыть баги оптимизатора

ulintb Dec 13 2011 at 16:52

100500 ошибок из-за разности компиляторов

propulsivo Dec 14 2011 at 00:10

Однажды перешли на 2010 на середине проекта. После месяца исправления багов очень радовались, что можем вернуться к работе по проекту без еженедельных сказок и оправданий перед заказчиком.

DenisO Dec 14 2011 at 00:32

А какого типа и насколько крупный проект?

propulsivo Dec 14 2011 at 01:03

Интеграция нескольких систем, для чего пытались использовать сначала стандартные очереди, потом самописные реализации очереди. Также постигло большое разочарование с мылом, в результате чего мыльная часть была частично написана без библиотек типа net.mail, а частично с ними. Вобщем-то использовали, если ничего не перепутал, только smtp отсылку из этой библиотеки, остальное самостоятельно реализовавали, и долго правили из-за этого.

ivlis Dec 14 2011 at 16:05

А почему не допилили существующие решения?

propulsivo Dec 15 2011 at 01:30

Именно что допилили, но это заняло время.

super Dec 13 2011 at 15:59

Лет через 10-20 для тех-же операций не будет хватать миллионов терабайт памяти.

justabaka Dec 13 2011 at 16:37

> миллионов терабайт
эксабайтов

TheHorse Dec 13 2011 at 18:31

тысяча тысяч тысяч тысяч тысяч тысяч байт!

diamant Dec 13 2011 at 18:58

Тысяча двадцать четыре тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх байтов.

propulsivo Dec 14 2011 at 00:20

Вообще-то не совсем правильно, т.к. Гигабайт это 10^9 байт, а не 2^30.
Ну и все последующие после гигабайта это степени основания 10, а не основания 2.

Хотя та же википедия говорит о разночтении начиная с мегабайта.
В сущности это всего-лишь несоответсвите терминологии ГОСТа, по которым производят и маркируют накопители. Единицы измерения информации

diamant Dec 14 2011 at 00:46

Оперативная память измеряется в степенях двойки.

propulsivo Dec 14 2011 at 00:51

Именно потому эксабайт неравен тому, что вы написали.

diamant Dec 14 2011 at 00:55

Пичалька.

ekungurov Dec 14 2011 at 13:41

В этом самом ГОСТе 8.417-2002 написано следующее: «Исторически сложилась такая ситуация, что с наименованием „байт“ некорректно… использовали (и используют) приставки СИ: 1 Кбайт = 1024 байт, 1 Мбайт = 1024 Кбайт, 1 Гбайт = 1024 Мбайт и т.д. При этом обозначение Кбайт начинают с прописной буквы в отличие от строчной буквы „к“ для обозначения множителя 10^3». Хотя да, особые педанты могут продолжать настаивать на мебибайтах, гибибайтах и прочих причудливых словах.

propulsivo Dec 15 2011 at 01:32

Как бы то ни было, Мегабайт не равен Мбайту. Тут или математика или слэнг, выбирайте сами.

ScratchBoom Dec 13 2011 at 16:07

Надо же было столько понаписать…

DmitryMe Dec 13 2011 at 20:19

Это не обязательно написанный руками код. Что-то может генерироваться автоматически, что-то — результат инстанцирования шаблонов в C++.

gibson_dev Dec 13 2011 at 16:13

прямо как компиляция сетевых библиотек буста (Boost) там влегкую за пределы памяти можно выйти на 32 битах)))

noonesshadow Dec 13 2011 at 16:19

В современных браузерах строк исходного кода больше, чем в ядрах современных ОС…

eugenius_nsk Dec 13 2011 at 16:26

Современные браузеры стремительно становятся современными ОС.

UFO landed and left these words here

MrLoki Dec 13 2011 at 17:11

Интеграции с браузерами, для обеспечения максимально комфортного симбиоза?)

serf Dec 13 2011 at 17:41

Похоже скоро стоит ждать первенца как результат этого симбиоза )

ggJa Dec 13 2011 at 18:01

chromium os?

serf Dec 14 2011 at 20:43

И действительно, правда есть мнение что он какой-то недоношенный получился.

ggJa Dec 14 2011 at 22:03

Я ставил, да сыроват, а если запускать не с харда, а с флэшки, так еще и тормозит ужасно. Как говорят, первый блин комом.

alist Dec 13 2011 at 17:56

Кто-то на Микрософт за это в свое время в суд подавал. А они оказывается все заранее предвидили!

frog Dec 13 2011 at 17:47

к BIOS'у

Xlab Dec 13 2011 at 18:39

К квадратикам

Paxa Dec 14 2011 at 09:23

К любви и гармонии

TIgorA Dec 13 2011 at 16:24

А что не так с переходом на х64 платформу?

mr_avi Dec 13 2011 at 16:28

Нарвеное чтобы проверить скомпиленное нужно будет переходить в 32-битную ОС.

TIgorA Dec 13 2011 at 16:33

Я думаю в мозилле не дураки сидят, и у них в виртуалках целый зоопарк ОС.

Правда с Mozilla 3.0 у них вышел былинный отказ. Самая первая 3.0 версия не хотела стартовать на Win7 x64.

SiGMan Dec 13 2011 at 17:12

даже у x64 msvc линкер 32х битный. а проблема как раз в нем

PQR Dec 13 2011 at 21:19

Судя по одному из предложенных вариантов «перейти на MSVS 2010» — там линкер уже 64х битный?

SiGMan Dec 14 2011 at 00:05

Нет, просто он чуть бережнее обращается с памятью.

amirul Dec 14 2011 at 08:47

Во первых линкер есть и такой и такой. Во вторых, они уперлись в предел 3Гб адресного пространства, а wow64 процессам (32-битные процессы на 64-битной системе) отдаются вообще все 4Гб адресного пространства (если бинарник говорит о том, что он согласен с тем, что старший бит в указателях может быть ненулевым — а link.exe имеет поддержку больших адресных пространств испокон веков — собственно это тот же флаг, который включает поддерку /3GB для процесса). В общем на полгодика б хватило — а там все равно весь девелопмент переводить на x64. Хоть так хоть эдак. Ну или отключать PGO

SiGMan Dec 14 2011 at 09:55

Нет, эт все понятно — не хотят переводить билдеры на 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.

amirul Dec 14 2011 at 12:51

Это откуда цитатка (интересно посмотреть на уровень неадеквата)?
Вот это из VS2010 (есть подозрения, что и в более старых версиях все так же, но проверить мне сейчас негде — старых версий нигде не осталось)

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

bruce Dec 15 2011 at 13:26

Так дело в кросскомпиляторе. Им все равно, нужно собирать бинарники для x86, но с помощью линкера и компилятора, которые сами работают на x64. (Кстати, линкер вызывает компилятор для некоторых задач в режиме PGO, так что нужны обе вещи). Microsoft сейчас такую возможность не предоставляет.

amirul Dec 16 2011 at 01:40

Да, я действительно не подумал, что для LTCG нужен бекэнд компилятора, а для генерации x86 кода он есть только в x86 варианте. Ну в таком случае им нужно серьезно подумать о рефакторинге одного монолитного бинарника в несколько более меликих.

Ну или попрофайлить и выяснить где получается наибольший выигрыш от PGO (наиболее «горячие» участки кода) и оптимизировать только эти места, а не все подряд.

auric Dec 16 2011 at 12:13

Прошу прощения за оффтоп, но что это за программа, скрин которой был представлен?

amirul Dec 16 2011 at 21:47

Это Process Hacker. По большей части дублирует функционал Process Explorer Руссиновича, но в некоторых вещах превосходит его.

amirul Dec 14 2011 at 12:53

> Так и так линкер упрется в 4Гб адресного пр-ва на PGO.
Пока что он уперся в 3Гб, а в прошлый раз (начало 2010) — в 2Гб. Так что один дополнительный гиг доступных адресов дал бы им возможность оставаться в прошлом еще год-два.

SiGMan Dec 14 2011 at 18:40

Спасибо)

serf Dec 13 2011 at 16:43

А я рад что и разработчики тоже испытывают сложности связанные с потреблением памяти их поделки.

Huntlet Dec 13 2011 at 16:49

А какая связь с потреблением памяти самим firefox???

mr_avi Dec 13 2011 at 17:07

и тот и тот едят много памяти

serf Dec 13 2011 at 17:51

Это почти синонимы, к сожалению, но слышал что ведется работа в этом направлении, и осчастливить нас хотят уже через несколько месяцев (в 10й версии вроде как).

markoffko Dec 13 2011 at 21:49

Ну клевая же шутка.

cyberbobs Dec 13 2011 at 16:55

Как связаны потребление памяти линкером при использовании PGO и потребление памяти самим Firefox?

lightman Dec 14 2011 at 10:58

Это что-то вроде метафоры.

serf Dec 13 2011 at 17:01

Отвечаю всем, связь такая что это рыжее чучело, после для работы (все вкладки закрыты), может кушать 1.5 Гб. Так вот, я рад что у разработчиков лисы тоже есть проблемы с памятью, мне пофиг какого они характера проблемы, но так они лучше поймут пользователей.

PS все равно его люблю )

serf Dec 13 2011 at 17:01

… дня работы…

tangro Dec 13 2011 at 17:17

Разработчики выкрутятся, Вы даже не сомневайтесь — и тот метод, которым они выкрутятся (будет ли это разбивка на модули или компиляция под х64) нифига не поможет конечному пользователю с его проблемами потребления памяти браузером.

serf Dec 13 2011 at 17:27

Конечно выкрутятся, на то мы и разработчики :)

serf Dec 13 2011 at 17:48

Просто сам факт того что им придется выкручиваться доставляет. Даже вспоминается недавняя проблема с госдолгом США, отложат еще раз (не проведут глубокий рефакторинг), всплывет снова через годик.

Raphael Dec 13 2011 at 17:25

UpTime рыжего чучела 8 версии порядка полутора недель, открыто в среднем около 20 вкладок в трёх группах вкладок, кушает 400 метров с фаербагом и адблоком, может проблема не в самом чучеле-то?

guyfawkes Dec 13 2011 at 17:32

Используете ли вы в разработке что-то подобное ExtJS, например? :)

Raphael Dec 13 2011 at 18:00

Нет, я бэкэндщик по большей части, а что там с ExtJS? Из-за него хромает только лиса?

shmaltorhbooks Dec 13 2011 at 18:09

firebug при активной работе с ExtJS показывает чудеса текучести памяти. того и гляди сам firebug за пределы памяти вылезет)

Raphael Dec 13 2011 at 18:11

Ну вот, один серьёзный и огненный баг в огненной лисе нашёлся, осталось быстренько пофиксать его! :)

UFO landed and left these words here

proxor Dec 14 2011 at 09:03

Так может всё-таки firebug течёт, а не firefox?

andreymo Dec 15 2011 at 13:09

Проверено, однозначно firebug. Но они тоже вроде исправляются. Совсем недавно научились очищать память при обновлении страницы, уже вперед.

Pilat Dec 13 2011 at 17:49

Зайдите на сайт с детскими играми — как делает каждый день мой трёхлетний сын — и будет гигабайт минимум. Вроде всего-то простенькая аппликация, а память летит только так.

Raphael Dec 13 2011 at 18:06

Игры же на Flash скорее всего?

Pilat Dec 13 2011 at 18:22

да, но памяти тем более течь не должно.

proxor Dec 14 2011 at 09:04

Как будто во флеше не может быть утечек, особенно если писано индусами.

Pilat Dec 14 2011 at 10:32

Мне казалось, что после закрытия странички с флэшем утечка памяти, вызванная флэш плагином, должна пропадать. Не пропадает же. Значит не индусы виноваты, как Вы думаете?

proxor Dec 14 2011 at 10:40

about:memory посмотрите сначала. И сколько ест plugin-container в процессах. Если вы флешку закрыли — это не значит, что там по волшебству вся память осободилась.

bear11 Dec 14 2011 at 11:45

Если вы флешку закрыли — это не значит, что там по волшебству вся память осободилась.
А куда же она девается-то, если не освободилась? Зачем лиса её держит, как сыр?

proxor Dec 14 2011 at 11:59

Всё что угодно может быть. Начиная сборщиком мусора (который и у флеша тоже есть) и заканчивая невозможностью освободить участок памяти (хотя последнее скорее выдаст run-time error).

Pilat Dec 14 2011 at 19:31

Учитывая, что FireFox ориентируется на плагины сторонних разработчиков, он должен сам следить за тем, чтобы эти плагины хотя бы после прекращения работы не потребляли память. Раз не следит — это вина разработчиков FireFox. Тут можно спорить только если поставить целью во что бы то ни стало продвигать тезис о непогрешимости FireFox.

proxor Dec 14 2011 at 20:02

Смеётесь что ли? Это как если бы вы просили Microsoft следить за всеми программами сторонних разработчиков для Windows.

Pilat Dec 14 2011 at 20:13

Я Вас сейчас насмешу: Микрософт это и делает. И это делает любая операционная система, это её профильное занятие. Программа запустилась, нагадила в отведённой ей памяти, закончила работу — память вернулась в систему.

betrachtung Dec 13 2011 at 21:35

Рыжее чучело Iceweasel 3.6.24, полсотни вкладок, четыреста мегабайт. Временами доползает до пятисот-шестисот. Аптаймы многодневные, а то и многонедельные.

ColorPrint Dec 14 2011 at 20:30

У меня хром с ~20-25 вкладками ноут с 6 гигами памяти в своп уводит иногда :(
Так что далеко не только у лисы проблемы.

lightman Dec 14 2011 at 10:59

Да ладно бы, пусть кушает хоть два гигабайта, но пусть не тормозит «за эту цену»!
Тормоза Firefox вымораживают гораздо больше, чем потребление памяти.

serf Dec 14 2011 at 11:03

А может тормоза следствие того что его разжиревшее пузо по земле таскается )

Vertex Dec 13 2011 at 16:58

Не хочется разводить холивар, Firefox отличный браузер, и навсегда останется в памяти, но лично мне больше по душе Chrome, и основной причиной перехода (причем почему-то довольно сложного для меня было), это именно из-за того, что он на маке сильно долго грузился (да и не только на маке).

DeusModus Dec 13 2011 at 17:05

При чем тут вообще Chrome и Mac, когда речь идет о проблемах компиляции?

baka_cirno Dec 13 2011 at 17:06

>Firefox отличный браузер, и навсегда останется в памяти

Звучит угрожающе.

Vertex Dec 13 2011 at 17:16

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

Хотя если вы имеете ввиду что он на текущий момент зависает в памяти надолго, то тогда да — звучит более угрожающе, грозит перезагрузкой. :)

eugenius_nsk Dec 13 2011 at 17:16

Звучит похоже на сообщение Windows ;-)

anthonio Dec 14 2011 at 03:37

новая услуга: очистка памяти от сторонних программ.

jazbit Dec 13 2011 at 17:19

> навсегда останется в памяти

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

(извините не удержался)

Creat1ve Dec 13 2011 at 17:06

Может я чего-то не понимаю, но по-моему самый идеальный вариант на сегодняшний день — разбить части кода на библиотеки. Это и оптимальней, и время компиляции сократится (не придётся компилировать лишний раз то, что уже скомпилировано), и отладка проще.

Maxmyd Dec 13 2011 at 17:15

Maxmyd Dec 13 2011 at 17:19

Сорри, гуглоплюс не отдал картинку :(

dom1n1k Dec 13 2011 at 19:23

Похоже на волка из мультика:
— Сы-па-сы-ба… Ну ты заходи, если шо!..

Niipaza Dec 14 2011 at 12:04

собрала операционка все браузеры и говорит: — того, кто будет безмерно жрать память — буду бить по наглой рыжей морде. (с)

agmt Dec 13 2011 at 17:16

«Firefox не вмещается в 32-битное адресное пространство»
Может всё-таки, компилятор Firefox не вмещается? У самого продукта с памятью пока запас есть.
Да и (3) решение выглядит слишком очевидным. В-общем, моё субъективное мнение: проблема не стоит даже того, чтобы в баг-лист добавлять.

dreamjke Dec 13 2011 at 17:48

Вы забыли про автора топика

Maxmyd Dec 14 2011 at 11:18

Мне кажется, или в каждом посте вышеозначенного автора есть такой коммент? :)

meako Dec 13 2011 at 17:22

PAE и серверная версия виндовса для компиляции?
Вобще, у проблемы масса решений, и она скорее не является чем-либо серезным, а просто забавным случаем.

agmt Dec 13 2011 at 17:35

PAE позволяет всей системе адресовать больше физической памяти. Процессу будет выделяться всё равно такое же количество виртуальной памяти.

meako Dec 13 2011 at 18:25

По большому счету да, хотя, насколько мне известно существуют хаки. А википедия вот говорит, что с PAE процессу выделяется 4 гигабайта.

leotsarev Dec 13 2011 at 18:42

С PAE в одном процессе можно адресовать 4 гигабайта, как и везде на 32-битных процах x86.
Вопрос только в том, что гигабайт зарезервирован под нужды системы.