Разработчики проекта Mozilla представили (http://blog.mozilla.com/luke/2012/01/24/jsruntime-is-now-off.../) изменения в организации работы JavaScript-движка SpiderMonkey (https://developer.mozilla.org/en/SpiderMonkey), в котором был серьёзно изменен подход к организации параллельного выполнения JavaScript-кода. Движок теперь будет работать только в однопоточном режиме, а распараллеливание, например, при выполнении WebWorkers (http://dev.w3.org/html5/workers/) или Parallel Javascript (http://smallcultfollowing.com/babysteps/blog/2012/01/09/para.../), будет обеспечено за счёт запуска внутри одного процесса отдельных экземпляров SpiderMonkey (JSRuntime), каждый из которых использует непересекающиеся области памяти.
Таким образом, SpiderMonkey больше не будет распараллеливать работу в рамках одного экземпляра JavaScript-движка (каждый из которых физически является экземпляром процесса JSRuntime), но будет на каждый новый обрабатываемый источник запускат...URL: http://blog.mozilla.com/luke/2012/01/24/jsruntime-is-now-off.../
Новость: http://www.opennet.me/opennews/art.shtml?num=32905
Давайте уже поскорее 11-ую версию Firefox-а допиливайте, которая не будет течь!
Да, ждемсъ... 10b еще течет, 126mb (в 18:28) при запуске с расширениями в простое без вкладок 184mb (19:14). Нужно еще последить за чистой лисой. А вот 12а-ночная еще падает, от каждого чиха, по сравнению с ней chromium_snapshots как debian stable ;)
А где она у вас падает? А то у меня почему-то не падает.
Где-где, в венде. =)
> Где-где, в венде. =)у вас может и в винде, у меня только линукс
Час работы и память за пол гига, часа 3 и уже за гиг, вчера заснул ночью после работы при просмотре онлайн фильма, на утро KDE висит, начинаю разбираться, висит начинаю разбираться, подвесила прога отсылающая баг-рапорт.:))) Идиотизм просто!
И кстати при падении и отправки рапорта, и такое у меня часто, причём внезапна, при нажатии на кнопку send and restart у меня никогда сам firfox не перезагружается после этого.
http://www.youtube.com/watch?v=aHF5uoonR-c
У меня что в винде, что в Убунту 12я отлично себя чувствует.
12-ая не 9-ая!
У меня 11-ая аврора то же работала стабильно, не считая того что она только 32-битная, в которой тормозит 32-битный флэш, не работает mozilla-kde-integration и превязка к протоколам...
Собирать из 1-ого гига исходников у меня желания нет.
В репах openSUSE только стабильная и бэта, причём в бэте не работает kde-integration что для меня не удобно.
> 12-ая не 9-ая!Ну тема начиналась кагбэ с жалобы на 12ю.
> не считая того что она только 32-битная
Враньё. На ftp мозиллы доступна как 32-битная, так и 64-битная сборки. Качай какую хочешь.
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/
Вот, например:
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/firef...
64-битный флэш в ней работает, не могу сказать тормозит он особо или нет (у меня он всегда тормозил).> mozilla-kde-integration
не работает потому, что это, я так понимаю, это расширение. На сколько я помнбю в 12й выпилили проверку версии так что может и заработать. А можешь сам выключить проверку версии принудительно если всё равно отметит как несовместимое.
> Враньё. На ftp мозиллы доступна как 32-битная, так и 64-битная сборки.там и брал.
> 64-битный флэш в ней работает, не могу сказать тормозит он особо илиработает, но сильно падуч сам браузер, причин не знаю. даже закрытие вкладки может его убить.
> На сколько я помнбю в 12й выпилили проверку версии так что может и заработать.
мне пришлось ставить расширение для отмены проверки.
>Враньё. На ftp мозиллы доступна как 32-битная, так и 64-битная сборки. Качай какую хочешь.
>ftp://ftp.mozilla.org/pub/firefox/Что то НЕ нащёл я тут 11-ой авроры! А nigtly она как миниум, без локализации, что в принципе не критично. но для меня не очень удобно.
>Ну тема начиналась кагбэ с жалобы на 12ю.Тема начиналась с просьбы не отвлекаться на второстепенные вещи и поскорее перевести 11-ую версию из авроры в релиз.
>> mozilla-kde-integration
>не работает потому, что это, я так понимаю, это расширениеДа это расширение, и оно в менеджере расширений отмечено как совместимое и рабочее, но всё равно open/save диалоги выдаются гномовские. Почему уж не знаю, сам firefox скорее всего тут и не причём, но факт остаётся быть фактом.
> вчера заснул ночью после работы при просмотре онлайн фильма, на утро KDE висита plugin-conteiner солько занимал на утро? или он был заранее отключён через about:config (в этом случае С.С.З.Б :)) ?
Не смотрел, хотя если сам firefox был уже в ауте, то логично предположить что plugin-conteiner был там же.
А память жрёт, если верить процессам, именно firefox.
Вот скажите, что я делаю не так что у меня он за 2 недели как жрал гиг на типовом наборе вкладок, так и жрет его же, с точностью до плюс-минус сотни мегов. У меня свопа вообще нет, если б там текло - я должен был бы давно откинуть лапки по OOM. Может, у вас профайл зверски загажен и вам стоит попробовать создать чистый?
> загажен и вам стоит попробовать создать чистый?с чистым тоже самое и about:memory занят сайтами которые как полдня были закрыты... и расширения тут не причем как пишут мозиловцы. Проверял и на чистом браузере и профиле.
>за 2 недели как жрал гиг на типовом наборе вкладок, так и жрет его жеНу вы батенька и Петросян :))
По вашему гиг для браузера это нормально!
1 Держать браузер открытым и активно работать в нём - это немного разные вещи.
2 Возможно он и у меня дальше гига не заходит, но для меня это, как бэ сказать, слишком жирно, и мне приходиться его перезапускать, что приводит к высвобождению почти три четверти гига!
Батенька, не пользуйте нетбуки с маленькой памятью. Я давно пришел к выводу что для нормальной работы 8Г это минимум.
Пара виртуалок и пара браузеров на полтора-два гига.
И кстати не надо гундеть, что хром ничего не жрет - жрет и не давится. Раз в неделю я его перезапускаю. и вместо двух с половиной гигов он начинает занимать мегов пятьсот. но за неделю опять жиреет до двух с половиной.
> подвесила прога отсылающая баг-рапорт.:))) Идиотизм просто!А где был OOM killer? Пиво пил?
Вот честно говоря не знаю, может быть его у меня в openSUSE по дефолту вообще нету...
Правильно! Вместо того, чтобы хардкорно лечить браузер, давайте его кастрируем!
нет блин.. давайте его не "кастрируем" (что коррекнее былобы назвать "вырежем опухоль") -- а будем нагромождать наисложнейние запутанные технологии синхронизации между объектами Javascript среды??? :-D :-D [технологии, которые одновременно: какбы и не тормазят, и какбы безопасные :-D :-D :-D]уже 100500 уязвимостей было найдено вертящихся около тематики того что происходит сложная перестройка DOM-дерева и в определённый момент паралельно-работабщий скрипт (<script async="true">...</script>) делает обращение к объекту этого перестраивамого DOM-дерева
очевидноже -- что куда прощще предоставить каждой отдельной Ните (Thread) Javascript-кода -- отдельный экземпляр js-движка.. и обмениться статусом между движками -- через сообщения, а не через хренову тучу механизмов синхронизации.
А что, неплохо. Получается дедупликация объектов в памяти.
это пц
они держали разные вебсайты в одной области памяти ?
кто же у них головой думает ?
В браузерах издавна так было. Это со времен хрома пошли эти виртуализации, "каждой сущности - процесс" и т.д. Так что ваше удивление удивительно.
Так все всегда делали и только с очень недавнего времени перестали. Это позволяло очень сильно сэкономить память при табиках.
я правильно понимаю, что "потоки" станут значительно тяжелее? раз надо весь рантайм каждый раз подгружать
Да и серьёзно. см. Гугл браузер.
тока у гугл браузера весь рантайм (включая то, что у мозиллы разбросано по разным архивам и собирается через механизм chrome) в зиготе, которая при старте процесса форкается и все быстренько подбирается не с диска, а напрямую из дискового кэша.
А чего ради оно должно заново с диска читаться? Ну будет создаваться новый объект JSRuntime - и что? Я еще понимаю, что памяти оно жрать может больше, но диск и кэш здесь при чём? Да даже если и читается что-то - никто не отменял фабрики, которые создают заранее отконфигурированны экземпляры класса...
потоки теперь будут рантаймами, а рантайм станет процессом если читать оригинал, и ничего не поменяется после соответствующих изменений кода.
Процесс с потоком не путайте, пожалуйста.
В оригинальной статье говорят, что такой вариант наоборот экономит память
> В оригинальной статье говорят, что такой вариант наоборот экономит памятьЭлементарная логика подсказывает, что в статье выдают желаемое за действительное.
Основная идея состоит в том, чтобы по возможности скопировать изолированную модель хрома. А какой у нее расход памяти - можно не рассказывать.
>SpiderMonkey больше не будет распараллеливать работуЗато вон как звонко кукарекали про Rust, про МЕГАГИТЛЕРМНОГОПОТОЧНОСТЬ. Докукарекались.
Так то было про DOM.
поменяйте заголовок новости.. сенсационная желтезна какаято!не "Используемый в Firefox JavaScript-движок будет работать только в однопоточном режиме"
а [например] "Рефакторинг многопоточной модели реализации Javascript в Firefox"
....ато так написали заголовок как будтобы Firefox деградирует :-D
# p.s.: хотя с другой стороны -- получился "заголовок-детектор". можно определять кто из комментаторов читает полностью новость, а кто только заголовок :-D
> поменяйте заголовок новости.. сенсационная желтезна какаято!
> не "Используемый в Firefox JavaScript-движок будет работать только в однопоточном режиме"
> ....ато так написали заголовок как будтобы Firefox деградирует :-DДа, надо было написать "Firefox опять пытается повторить подвиги Chrome - ждите очередное увеличение жрача памяти".
И на винде с её убогими тормозными процессами станет весело.
А новость лучше таки читать. А еще лучше - еще и оригинал. Речь всего лишь о том, что различные JS-потоки будут взаимодействовать по схеме share-nothing, в рамках одного процесса.