Компания Google представила (http://google-opensource.blogspot.com/2012/08/leak-finder-ne...) новый открытый инструментарий Leak Finder (https://code.google.com/p/leak-finder-for-javascript/), предназначенный для выявления утечек памяти в JavaScript-программах. Под утечками памяти подразумевается наличие объектов, которые не освобождаются сборщиком мусора из-за привязки к структурам данных JavaScript-библиотек, но уже не используются в пользовательском приложении. Утилита написана на языке Python и распространяется под лицензией Apache. Использование утилиты производится вкупе с браузером Chrome при помощи протокола удалённой отладки.
URL: http://google-opensource.blogspot.com/2012/08/leak-finder-ne...
Новость: http://www.opennet.me/opennews/art.shtml?num=34534
>Под утечками памяти подразумевается наличие объектов, которые не освобождаются сборщиком мусора из-за привязки к структурам данных JavaScript-библиотек, но уже не используются в пользовательском приложении.Ничего не понял. Разве не этим и должен заниматься сборщик мусора?
может сборщик мусора ещё и патчи в ядро linux должен отправлять сам? :-D
А чего ему собирать? Это же не классическая утечка, а скорее неоптимальное использование, сборщик это не искусственный интеллект, приложение держит данные (библиотеки используемые в приложении) ну а раз держит то подразумевается что они нужны, вот память и не освобождается, как только станет понятно что эти данные не нужны (программист очистит список и т.п.) память автоматически освободится.
> А чего ему собирать? Это же не классическая утечка, а скорее неоптимальное
> использование, сборщик это не искусственный интеллект, приложение держит данныеТак в случае любой утечки примерно такая же ситуация, вид в профиль. В чем состоят 10 отличий? В том что утечки "теперь банановые"? Память то жрется одинаково :)
Жрется то одинаково, но причины разные, чуть ниже подробно описано.
> Жрется то одинаково, но причины разные, чуть ниже подробно описано.Причины тоже примерно одинаковые, с точностью до сильно некоторых деталей.
ну этак вы дойдете до идеала вроде все есть все)
Сейчас 95% яваскриптеров поделит на ноль: они думали что утечек памяти в JS не бывает. А тут вдруг как гром среди ясного неба утилита для борьбы с ними :)
Нужно просто сделать еще 1 язык поверх яваскрипта! Со своим сборщиком мусора, тогда точно не будет утечек!
Не надо ничего делать, классических утечек итак нет, а то что конкретный программист вообще перестает следить за тем что делает, никаким языком не лечится.
> Не надо ничего делать, классических утечекА что такое классическая утечка памяти? И чем отличается от НеКлассической (tm)?
> итак нет, а то что конкретный программист вообще перестает следить за тем что
> делает, никаким языком не лечится.Внезапно. Оказывается, если вы где-то продолбали некую сущность - она будет висеть в памяти и жрать ее. При том не так уж важен ЯП и конкретная модель управления памятью. Надо же, сюрприз! :)
p.s.: жила была приблуда. Юзала extJS. Ну так вот, за ночь клала любой браузер. Забыли вкладку? Чпокс - браузер жрет под 2Гб памяти через 8 часиков :)
Вон там ниже по этому поводу уже было:Утечка утечке рознь, сишных утечек (т.е. когда программист сказал что объект ему не нужен - убрал/обнулил ссылку, но память при этом не освободил) в JS нет, а вот когда он совсем не чешется (никак не сообщает о том что данные ему больше не нужны и это невозможно выяснить логически - не очищает уже не нужные списки, не закрывает файлы и т.п.) тогда да, всеравно получается утечка, другого рода как понимаете, но результат тот же.
под "классической" понимается "сишная" утечка, во первых она какбы и более известна и сравнительно раньше появилась, во вторых это "настоящая" утечка, ибо память никак в принципе высвободить нельзя, т.к. все ссылки потеряны, в отличие от JS где на стороне в данном случае либы ее высвободить всетаки можно. Ну и в третьих, конечно спорно, не знаю как выразиться, поэтому и написал "классическая", но представленная выше JSная утечка хоть конечно и утечка, но сильно на раздолбайство смахивает, захавать память и держать, практически специально, ибо не предпринимать совершенно никаких действий чтобы ее освободить, возможно поэтому кстати и в самой новости специально выделено что подразумевается под утечкой.
Ну т.е. разница грубо говоря в том что в первом случае человек ошибся с реализацией, а во втором даже и не собирался. Если в первом случае еще както можно ссылаться на сложность языка, то во втором уж чисто вина программиста. Когда у вас кролики с голоду подохли одно дело если у вас на покосе коса сломалась, может в нее вдруг молния ударила, не знаю, но совсем другое если вы даже и не выходили) Ну вот короче както так, надеюсь разница понятна. А результат к сожалению конечно один.
>А что такое классическая утечка памяти? И чем отличается от НеКлассической (tm)?Классическая - забыли освободить явным образом, а указатель уже нигде не хранится.
Не классическая - указатель доступен программе и указывает на область памяти, к которой программа больше никогда не обратится.
Ваш КО.
> итакИтак ... итак что? Поставьте ему двояк в четверти по русскому языку.
гуляй
> гуляйИ этому тоже двойку в четверти за безграмотность.
>Сейчас 95% яваскриптеров поделит на нольВообще ваш сарказм от незнания. Нужно читать историю. В реальности, JavaScript является более совершенным языком, чем даже джава. И то и другое проистекает из недр недавно покинувшей этот мир Sun.
Однако узколобые менеджеры сказали, что нефиг делать космические корабли и скайнет, лучше мы займёмся апдейтом морально устаревшего си++. Вот так и получилось, что Java победила и надолго закрепилась в умах программеров, тогда как JavaScript остаётся уделом низкоквалифицированных кадров. Архитектура JavaScript позволяет перееопределять объекты в реальном времени, а не втискиваться в узкие рамки типизации. Но увы, никто вам не скажет, что первое намного сложнее чем второе, а также то что языки с динамической типизацией могут в теории достигать очень и очень хорошей производительности.
>>Сейчас 95% яваскриптеров поделит на ноль
> Вообще ваш сарказм от незнания. Нужно читать историю. В реальности, JavaScript является
> более совершенным языком, чем даже джава. ...верно-то оно верно (javascript более програссивный и сложный (гибкий) чем java) -- но вот только много-ли современных школо-программистов об этом знает? :-)
чать людей кто пишет на javascript -- даже не понимают суть прототипов.
> Архитектура JavaScript позволяет перееопределять
> объекты в реальном времени, а не втискиваться в узкие рамки типизации.Для больших приложений это минус. Как сделать контракт между подсистемами, развиваемыми в разных командах или даже компаниях? Как проверить, что вызывающий код прислал объект правильного типа?
А никак - только рантайм проверки, что требуемые переменные заданы в рамках пришедшего объекта. Только эта проверка очень прожорлива. Можно, конечно, положиться на авось, но обычно это выстреливает багами в самый не подходящий момент.
PS java не идеал, но динамические языки имеют еще больше минусов.
>> Как проверить, что вызывающий код прислал объект правильного типа?type of
Ваш, КО.
>>> Как проверить, что вызывающий код прислал объект правильного типа?
> type of
> Ваш, КО.Тогда код будет пестрить проверками type of, особенно если ты пишешь библиотеку и кто угодно может вызывать твой код.
Когда это же делает компилятор, и ешё сразу в среде разработки подсвечивается ошибки в случае неправильного кода - намного приятнее и удобнее. И естественно код более надёжный.
> Тогда код будет пестрить проверками type ofБудто в статическом коде этого нет, а с учетом описаний явной типизации так и того возможно больше.
>> Тогда код будет пестрить проверками type of
> Будто в статическом коде этого нетпри статической типизации type of в 95% не нужен - тип описывается типом переменной или парметра. оставшиеся 5% это универсальный код, которых работает с AST или делает downcast.
в отличии от этого в динамических языках придется или верить в то, что код работает с правильными типами (возможно для малых приложений или небольших скриптов) или фаршировать код пачками type of.
Верить в то, что код работает с правильными типами можно не только в малых приложениях, но и в весьма больших, для этого приложение разбивается на относительно небольшие модули, внутри них как вы понимаете проблем нет, а вот между ними простраивается интерфейс с четко определяемыми требованиями, для полной безопасности (если надо) при получении данных через этот интерфейс, осуществляется проверка на соответствие, в одном единственном месте на входе.
> вот между ними простраивается интерфейс с четко определяемыми требованиями, для полной безопасности (если надо) при получении данных через этот интерфейс, осуществляется проверка на соответствие, в одном единственном месте на входе.Собственно размер этого входа в больших приложениях - огромен.
Покажи плиз пример JS кода, который описывает типо-безопастный интерфейс. Пусть будет простая функция с одним параметром-объектом, который содержит ФИО + тип документа + идентификатор документа (номер паспорта для паспорта).
Да, а размер деклараций всех типов при статической типизации, и кучи извратов над этим чтобы обеспечить динамику, вроде всяких шаблонов и метатипов, еще больше)Делать полную строгую проверку типа в подавляющем большинстве случаев не требуется, это геморойно и сведет все плюсы динамики на нет, как правило достаточно проверить наличие и диапазоны входящих данных, чтото вроде if (!isfio(idoc.fio)) throw "блаблабла", ну в нашем случае будет 3 таких строчки, пожалуй и все.
> как правило достаточно проверить наличие и диапазоны входящих данных, чтото вроде if (!isfio(idoc.fio)) throw "блаблабла"Собственно как я и предполагал. Собственно вместо того, чтобы компилятор проверял типы еще при написании кода делается if() throw в каждом методе доступном извне.
Когда то (в 2007) сделал подобный изврат на JS. Даже на тестовых (довольно малых данных) оно жестко тормозило. Так что вместо просто указания типа приходилось постоянно то включать то выключать рантайм-проверку, чтобы залечить казалось бы простую проблему.
А то у вас так частенько не делается, да еще плюс своих косяков с метатипами и шаблонами хватает. То что динамика в принципе медленнее статики никто не спорит, у нее как известно другие плюсы, а при нормальном подходе она медленнее не сильно, так что смысл есть.Во первых такие проверки в принципе не изврат, и любой мало-мальски спец, если он не пытается притянуть осла за уши, это понимает, ибо просто статически проверить входящие данные часто не достаточно, их приходится несколько более хитро сопоставлять, в т.ч. с динамикой, а если даже и не так то всеравно, ошибку надо обрабатывать, и тут мы без них уже никуда не денемся.
А во вторых то что оно у вас жестко тормозило говорит о том что вы напихали их куда не попадя, выбрали неверную архитектуру, или вообще инструмент, т.е. под ту вашу задачу JS не подходил, это всетаки не парсилка/числодробилка, это высокоуровневый скриптовый язык, и задачи у него соответствующие. При нормальных же раскладах я еще ни разу не видел чтобы такие проверки вызывали жесткие тормоза, как правило есть другие более узкие места, и как правило вообще не с JS связанные.
> Будто в статическом коде этого нет,Нет, потому что компилятор мозг вынесет. И форсить преобразвания типов надо явно. Четко понимая что делаешь. А вот JS вообще довольно раздолбайский по синтаксису язык. И на типы пофиг, и переменные без декларации может объявлять.
...по поводу чего в самом интересном месте вылезает подлый баг. Который к тому же хрен поймаешь. Что очень доставляет крупным проектам.
В вашем может и нет, а мне приходилось ковырять статику в которой такого хватает, впрочем это уже конечно не совсем статика. Нифига он не раздолбайский, готовить просто не умеете) или не тем скармливаете) на типы пофиг, и переменные без декларации может объявлять - ну тык гы, ну динамика же) фича такая, при соответствующем подходе весьма удобно, а багов которые хрен найдешь и в статике хватает, классический пример - течи в сях.
> В вашем может и нет, а мне приходилось ковырять статику в которой
> такого хватает, впрочем это уже конечно не совсем статика.В случае статики надо как минимум возжелать прострелить себе пятку. То что это сцyкабольно - можно было догадаться. А тут прострел пятки самострелом получается.
> Нифига он не раздoлбайский, готовить просто не умеете) или не тем скармливаете)
Просто ряд граблеопасных бестолковостей в синтаксисе. А для скоростных применений - извините, типизированные данные еще и намного быстрее в плане работы с ними. На JS, да. И они вроде как часть стандарта нынче. Только вот - реализовано не всеми. Но игрушечники и прочие их лю. За скорость, прикиньте? :)
> на типы пофиг, и переменные без декларации может объявлять - ну тык гы,
Забойная аргументация - "гы" :)
> ну динамика же) фича такая, при соответствующем подходе весьма удобно,
То что карета при случае превращается в тыкву - фича, а не баг? :)
> а багов которые хрен найдешь и в статике хватает, классический пример - течи в сях.
Так они и на js есть. А еще для сей есть очень крутые и мощные утили типа валгринда которые в 2 счета ловят утечки. Просто отслеживая все аллокации вообще и при завершении работы проги ты просто получаешь список всех продoлбов. На сях такое делается как 2 пальца об асфальт. А в JS с этим вообще сложнее. Например JS тебе вообще не даст так по простому свой чекер/аллокатор вднплить, заоверрайдив системный на свой трассирующий выделения памяти с дeбажными целями.
Ды и не спорю же, косяки конечно есть, но и плюсы тоже, реально позволяет при определенных условиях меньше париться, и вполне нормально при этом решать задачу, давайте тогда чтоли залажаем визуальные/rad средства, не забудет си, ибо на машкодах труёвей и т.п, ну вы поняли о чем я, инструмент под задачу и спеца, ниша есть, и на том и на том пишу, реально есть.
> Ды и не спорю же, косяки конечно есть, но и плюсы тоже,Так чтобы были вообще одни минусы - это надо сильно постараться. Даже у brainfuck (ЯП такой) можно найти некоторые плюсы, во всех смыслах слова :)
> реально позволяет при определенных условиях меньше париться, и вполне нормально при
> этом решать задачу, давайте тогда чтоли залажаем визуальные/rad средства, не забудет
> си, ибо на машкодах труёвей и т.п, ну вы поняли о чем я, инструмент под задачу
> и спеца, ниша есть,Не, с тем что ниша есть никто и не спорит. Вебня там всякая - ну да, нормально. Пока мелкая. Когда становится крупной - начинается: оно и течет, и ресурсов жрет прорву, и баги неочевидные через полдня работы, так что фиг поймаешь. А оказывается что вон там опечатка и тебе услужливо завели новую переменную. В которой содержится ну совсем не то что ожидалось.
Более строгий ЯП в два счета меня пошлет - "ой, а что это?". А JS просто втихарика слопает. Зато потом где-то далеко это выстрелит. Не то чтобы это хорошо.
> и на том и на том пишу, реально есть.
А я вообще на брейнфаке пишу. Правда такая фигня получается...
на моей практике честно говоря от языка мало что зависит, мне удобнее перл/js/plsql, многим си, но течей, глюков, неочевидных ошибок и т.п. и там и там хватает, по моему гораздо важнее организация и квалификация исполнителей. Про крупные проекты можете не рассказывать, и менты и мо и гб и частные лавки и нефтекомпании, и зарубежные конторы, и это только один проект, с кучей языков.
и вы предлагаете на каждый параметр в каждой функции вешатьпсевдокод:
if(! obj type of SomeType) throw exception;?
и это удобство динамической типизации?
Только в том случае, если вы не умеете писать код, использующий динамическую типизацию..
> Только в том случае, если вы не умеете писать код, использующий динамическую
> типизацию..Ок. Покажи пример как правильно писать интерфейсный код используя динамическую типизацию.
Пусть будет простая функция с одним параметром-объектом, который содержит ФИО + тип документа + идентификатор документа (номер паспорта для паспорта).
И как будет поймана ошибка в вызывающем коде, если название поля фамилия было отрефакторено на другое (lastname -> soname).
+1
> Для больших приложений это минус. Как сделать контракт между подсистемами, развиваемыми в разных командах или даже компаниях? Как проверить, что вызывающий код прислал объект правильного типа?как раз приложения и становятся большими -- потомучто эти интерпрайзные программы на интэрпрайзных языкы программирования (со статической типизацией) -- содержат хренову тучу кода всяких интерфейсов для типовго согласования... если всё это дерьмищще поудалять то сразу оказывается что программа-то маленькая.
и главное возникает вопрос -- а почему вдруг в какуюту функцию передастся объект неправильного типа? потомучто кто-то забудет сделать parseFloat() после document.querySelector() ??? тыг вот такая говноошибка будет сразу замечена при первом тестировании :) !! а другую более серьъёзную ошибку допустить очень трудно при утиной типизации.
> как раз приложения и становятся большими -- потомучто эти интерпрайзные программы на
> интэрпрайзных языкы программирования (со статической типизацией) -- содержат хренову
> тучу кода всяких интерфейсов для типовго согласования... если всё это дерьмищще
> поудалять то сразу оказывается что программа-то маленькая.Да, объем кода реализации контрактов уменьшится. Зато увеличится трудоемкость проверки правильности входящих параметров. Т.е. интерфейсы без кода заменятся на код в КАЖДОЙ функции доступной из вне. Удобно - фигли )))
Вполне удобно, то время которое тратиться на написание проверок компенсируется временем на их выражение в чисто декларативном интерфейсе, плавали, знаем, то там не срастается, то сям, и приходится сидеть и чесать репу, время также уходит.
> не срастается, то сям, и приходится сидеть и чесать репу, время также уходит.Лучше получить очевидный отлуп компилера с тычком в проблемное место чем отхватывать через полдня работы программы какой-то нифига не очевидный баг который вообще фиг знает в каком месте вон той простыни порылся.
Неочевидных багов и в статике хватает
> Неочевидных багов и в статике хватаетСи вообще не то чтобы строго типизированный ЯП. Его типы - по сути просто compile time валидация. Можно обойти, если надо. Но это всего лишь защита от пальбы в пятку.
Для критичных применений в сях кстати есть убер-злые наборы правил позволяющие писать предсказуемые как часы системы. Например, полностью статичное выделение памяти заранее, прямо на старте. И допустим полный запрет на адресную арифметику.
А скажите, совсем не прикольно будет, если мелкий таракан в системе ABS автомобиля или системе электронного газа вдруг облажается память выделить? Этак из юзера может фарш выйти ненароком. Кстати утечки памяти при статичном распределении памяти исключены как класс: если память нельзя выделить, ее нельзя забыть вернуть назад. Вот это реально повышает надежность ;)
да вариантов куча, и нужно выбирать оптимальный под конкретные условия, а не единственно верный) хрена там JS, даже бейсик 20 летней давности может быть оптимален.
> и главное возникает вопрос -- а почему вдруг в какуюту функцию передастся
> объект неправильного типа? потомучто кто-то забудет сделать parseFloat() после document.querySelector()
> ??? тыг вот такая говноошибка будет сразу замечена при первом тестировании
> :) !! а другую более серьъёзную ошибку допустить очень трудно при
> утиной типизации.Потому что контракт изменился. Функция принимает на вход объект с полями firstname, secondname, soname (так обозвали ФИО) + passportNumber. Библиотека была доработана и поле фамилии было переименовано из soname в lastname. В java эта ошибка будет выявлена в момент компиляции зависимых проектов - compilation error поскольку старого поля просто нет.
В JS код пройдет валидацию и будет запущен (что ошибка дошла до рантайма уже плохо), но баг может и не проявиться, а ошибка может выскочить внутри библиотеки или, что еще хуже, будет использоваться пустое значение вместо Фамилии.
Статическая типизация тоже не идеал, но проблему согласования типов и полей она решает просто. Плюс рефакторинг поверх статически типизируемых языков работают намного лучше.
> Статическая типизация тоже не идеал, но проблему согласования типов и полей она
> решает просто. Плюс рефакторинг поверх статически типизируемых языков работают намного
> лучше.Ни чем не проще, пишу и на статических и на динамических языках, в общем разницы нет, просто применяются разные подходы, зато динамические при некоторых условиях позволяют лишний раз не напрягаться.
> некоторых условиях позволяют лишний раз не напрягаться.А в некоторых - могут заставить изрядно пое...ся с поимкой нифига не очевидного бага, который бы иначе пристрелил на корню компилер, чекавший типы при сборке.
Могут, да) но на практике мне например на том же перле писать да и поддерживать приятнее, количество багов и время на их исправление по сравнению например с сями однинаковое, хотя на делфе например кажется что поменьше, но там и сам процесс более муторный. Короче, каждому свое, холиварная тема)
Дельфя как и паскаль может быть излишне занудны. Но к порядку приучают хорошо. В си и подобных с этим как-то попроще. Но вообще-то послаблениями надо пользоваться только по делу. А то потом придется бухтеть в вашем стиле :)
Ога, или в вашем)
> Ога, или в вашем)В моем вы не сможете, увы. Объяснить почему, или сами догадаетесь? :P
О яваскрипте лишь крайне мало знаю, но был уверен что слова утечка и яваскрипт не могут быть в одном предложении...
Джавваскриптерам мешают джавваскрипт библиотеки! Ну, то есть не са-а-ами библиотеки, а привязка объектов к структурам данных библиотек. Понимаете?!! Вот так всё непросто.:`(
Утечка утечке рознь, сишных утечек (т.е. когда программист сказал что объект ему не нужен - убрал/обнулил ссылку, но память при этом не освободил) в JS нет, а вот когда он совсем не чешется (никак не сообщает о том что данные ему больше не нужны и это невозможно выяснить логически - не очищает уже не нужные списки, не закрывает файлы и т.п.) тогда да, всеравно получается утечка, другого рода как понимаете, но результат тот же.
> Утечка утечке рознь, сишных утечекДа, ежу понятно что в яваскрипте не может быть сишных утечек. Хотя-бы потому что JS != C :)
> О яваскрипте лишь крайне мало знаю, но был уверен что слова утечка
> и яваскрипт не могут быть в одном предложении...function xxx() {
// ...
obj.addEventListener(a, b)
// ...
}теперь при каждом вызове xxx() -- будет утечка ресурсов...
ну а вообще можно и такое сделать:
var my_list = []
function yyy(a) {
// ...
my_list.push(a)
// ...
}вот вам и типичная утечка памяти, при каждом вызове yyy(), если my_list не чистится
вобщем -- даже самый крутой сборщик мусора -- не сможет быть исскуственным интеллектом, исправляющим ошибки
а новомодная функция ``objectURL = window.URL.createObjectURL(file);`` -- это вообще рай для мусора :-)
>теперь при каждом вызове xxx() -- будет утечка ресурсов...Извините, но это утечка мозга.
>>теперь при каждом вызове xxx() -- будет утечка ресурсов...
> Извините, но это утечка мозга.Возможно стоило дальше расписать пример, что представляют из себя a и b?
> Возможно стоило дальше расписать пример, что представляют из себя a и b?я и сам не знаю :-D
..просто предположил что если очень быстро печатать код -- то можно случайно такое написать :-D :-D
> Извините, но это утечка мозга.То же самое можно сказать и про иные утечки памяти :)
Да не скажите, одно дело если человек ошибся из за сложности структуры и особенностей языка, и совсем другое если он откровенно положил.
> Да не скажите, одно дело если человек ошибся из за сложности структуры
> и особенностей языка, и совсем другое если он откровенно положил.Знаете, в простых случаях на си тоже сложно откровенно положить :)
Более того - явная аллокация памяти например позволяет ловить ошибки выделения этой самой памяти. В си если мы хотим блок на 100500 мегов который быть в принципе и не обязан - можно посмотреть: реально такое получить или облом. И сбой выделения можно поймать. А что в JS будет? Ну в общем по этому поводу он и пригоден для написания всякой развлекательной фигни. А например для системных дел где надежность нужна - не подойдет никогда.
Вы таки не поверите, юзается у меня для сбора инфы с контроллеров контроля доступа на режимном предприятии, и ниче, всех устраивает, а на сях писать некому.
> Вы таки не поверите, юзается у меня для сбора инфы с контроллеров
> контроля доступа на режимном предприятии,Я и не сомневался что совковые предприятия не готовы платить нормальным спецам. Потому и ж@пе. Наняли какого-то копеечного скрипткидя, потому что другие за такую ЗП не пойдут.
Скажи, чувак, а ты бы воткнул свою поделку в систему управления тормозами? Вот лично твоего авто? Вот это - хороший тест софта на гунявость, да. И кодера тоже.
> и ниче, всех устраивает, а на сях писать некому.
Это при том что си первый по популярности ЯП в мире? Я фигею, дорогая редакция. Просто сишники в отличие от скрипткидей освоивших пять минут назад "типа, программирование" не вкалывают за еду ;)
не выебывайся дитё
> крайне мало знаю
> но был уверенКак мило)
Вот, спорим, в разговор двух преподов вы с такими словами не вклинитесь?
Ничего вы не понимаете - это не утечки, это особенность такая! Надо просто чаще нажимать F5 и все будет хорошо. И компьютер после рабочего дня выключать (из розетки)
Отлично пошутил, молодец.