Заметил странное: если сайт течёт в IE11, то даже ничего не делая, рефрешить страницу- течёт. Только с закрытием таба память освобождается.
Конечно понимаю, чакра она штука сложная. Но всё же, кто-то сталкивался, может быть есть какие-то известные вещи, которые в IE текут? Может, CSS или ещё что?
Здравствуйте, Тёмчик, Вы писали: Тё>Конечно понимаю, чакра она штука сложная. Но всё же, кто-то сталкивался, может быть есть какие-то известные вещи, которые в IE текут? Может, CSS или ещё что?
Раньше в нём традиционно текла интеграция JS с DOM. Потому, что в JS там GC, а в DOM — RC.
В итоге, если к DOM элементу привесили скрипт, в котором есть ссылка на этот DOM элемент, то всё, трындец. Даже когда мы выносим этот элемент из children видимого элемента, на него по-прежнему сохраняется ссылка из скрипта; а скрипт собрать нельзя, т.к. на него есть ссылка из DOM.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Раньше в нём традиционно текла интеграция JS с DOM. Потому, что в JS там GC, а в DOM — RC. S>В итоге, если к DOM элементу привесили скрипт, в котором есть ссылка на этот DOM элемент, то всё, трындец. Даже когда мы выносим этот элемент из children видимого элемента, на него по-прежнему сохраняется ссылка из скрипта; а скрипт собрать нельзя, т.к. на него есть ссылка из DOM.
А это стандарт или имплементация мс? Зачем структуре данных (DOM) знать что-то о коде, с ней работающим?
Здравствуйте, Sharov, Вы писали:
S>А это стандарт или имплементация мс?
Во времена, когда я плотно работал с IE, это был более-менее стандарт. S>Зачем структуре данных (DOM) знать что-то о коде, с ней работающим?
Затем, что так устроен DOM. С его точки зрения, у элемента button есть атрибут onclick, который является ссылкой на скриптовый объект "замыкание".
Если строить DOM не на основе COM или аналогичной reference-counted неуправляемой технологии, а, скажем, на основе java- или javascript-объектов, то такой проблемы не возникает.
Здравствуйте, Sinclair, Вы писали:
S>>Зачем структуре данных (DOM) знать что-то о коде, с ней работающим? S>Затем, что так устроен DOM. С его точки зрения, у элемента button есть атрибут onclick, который является ссылкой на скриптовый объект "замыкание".
А нельзя ли их игнорировать при rc? Ведь это abstraction leak знать про какой-то код, который с тобой работает, зачем?
S>Если строить DOM не на основе COM или аналогичной reference-counted неуправляемой технологии, а, скажем, на основе java- или javascript-объектов, то такой проблемы не возникает.
А почему до сих пор не сделано, легаси? Почему это будет работать понятно -- gc умеет работать с изолированными графами объектов.
Здравствуйте, Sharov, Вы писали: S>А нельзя ли их игнорировать при rc? Ведь это abstraction leak знать про какой-то код, который с тобой работает, зачем?
Затем, что без этого код может обратиться по указателю, который показывает непонятно на что. В неуправляемом мире это может приводить к произвольным результатам. S>А почему до сих пор не сделано, легаси? Почему это будет работать понятно -- gc умеет работать с изолированными графами объектов.
Я не в курсе state of the art в этой области. Возможно — уже сделано. Возможно — нет, и считается, что браузер может быть только нативным и с детерминистической финализацией, безо всяких GC.
Вопрос по этому поводу в любом случае не ко мне, а к авторам оставшихся в живых браузерных движков.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали: S>>А нельзя ли их игнорировать при rc? Ведь это abstraction leak знать про какой-то код, который с тобой работает, зачем? S>Затем, что без этого код может обратиться по указателю, который показывает непонятно на что. В неуправляемом мире это может приводить к произвольным результатам.
Ну так это проблемы кода, который забыл отписаться. Почему это должны быть проблемы DOM?
Здравствуйте, Sharov, Вы писали:
S>Ну так это проблемы кода, который забыл отписаться.
Нет. Это проблема исполнения произвольного кода под привилегиями пользователя. В лучшем случае ОС пристрелит браузер. В худшем — мы будем иметь эскалацию привилегий.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Раньше в нём традиционно текла интеграция JS с DOM. Потому, что в JS там GC, а в DOM — RC. S>В итоге, если к DOM элементу привесили скрипт, в котором есть ссылка на этот DOM элемент, то всё, трындец. Даже когда мы выносим этот элемент из children видимого элемента, на него по-прежнему сохраняется ссылка из скрипта; а скрипт собрать нельзя, т.к. на него есть ссылка из DOM.
Супер, спасибо за логическое объяснение.
Я правильно понимаю, что сочетание
const nativeElement=.....
return ()=> {}
Создает классическую циклическую ссылку, от которых в теории, GC и призван защищать?
Неплохо бы иметь какой-то статический анализатор кода, чтобы явно требовал занулить все ссылки на DOM после работы с ними.
Такие есть?
Ещё странность: проблема с утечкой стоит остро для одного заказчика, но для другого намного менее остро, можно сказать, negligible. Между заказчиками код в рантайме местами имеет различную логику. Скажем, 1% кода отличаются, 99% общий.
Здравствуйте, Sheridan, Вы писали:
S>Ну право же, 21й год 21го века... ie? что это?
Жирный клиент требует IE, там течёт и тормозит. Все другие клиенты открывают в хроме, там почти всегда летает. Но тоже течёт, судя по хромовскому профайлеру — хотя и значительно меньше по цифрам в таск менеджере. GC говорили они, ручное управление памятью секс в гамаке, говорили они. Вот, по сути GC — отложенная проблема, когда оно течёт водопадом и непонятно, откуда оно растёт и недетерминированно недоочищается.
Microsoft полностью откажется от браузера Internet Explorer 15 июня 2022 года — спустя более чем 25 лет развития проекта. В официальном блоге Windows разработчики предупредили, что с окончательным прекращением поддержки ПО Interner Explorer 11 станет недоступно и прекратит работу на «определенных версиях Windows 10»
Здравствуйте, Evgeniy Skvortsov, Вы писали:
ES>Здравствуйте, Sheridan, Вы писали:
S>>Ну право же, 21й год 21го века... ie? что это?
ES>Слушай, ну хватит думать что весь мир ограничен твоим санаторием где ты самый крутой админ с последними технологиями в обнимку.
В санатории я уже не работаю лет этак шесть. Поработал в СпБ удалённо — оутсорсили кучу фирм — девопсил, программировал. Оттуда сманили в энергетику. Пишем софт для визуализации/управления/контроля энергосетей.
ES>Есть немало серьезного ентерпрайза, у которого фронт на сервеладе. И никто переписывать его не спешит.
Да, если в головах ветер немножко. А если с головами всё ок — то подобные апгрейды резерчатся, планируются, пишутся и внедряются.
Здравствуйте, Тёмчик, Вы писали:
Тё>Заметил странное: если сайт течёт в IE11, то даже ничего не делая, рефрешить страницу- течёт. Только с закрытием таба память освобождается.
Тё>Конечно понимаю, чакра она штука сложная. Но всё же, кто-то сталкивался, может быть есть какие-то известные вещи, которые в IE текут? Может, CSS или ещё что?
Сталкивались и не раз.
К сожалению практически во всех случаях находилась какая-то ошибка в самом и IE.
Благодаря подписке на поддержку от МС нам удалось донести это до разработчиков и в итоге ошибки починили.
Первым делом, убедитесь, что установлены все обновления.
Даже в минорном попадаются серьёзные починки утечек памяти.
Если это не решает проблему, то тут нужно обратиться в поддержку.
Для этого прежде всего нужно локально создать воспроизведение ошибки, чтобы сотрудники могли легко увидеть проблему.
Желательно этого проделать на чистой систему, скажем в виртуалке.
Далее есть два пути:
Первый найти того у кого есть Microsoft Premier Support, этот вариант самый эффективный.
Второй вариант это обычная поддержка и форумы MS, тут надо писать везде, где можно в надежде, что кто-нибудь да взглянет на проблему.
Как вариант придумать как этой ошибкой организовать, что-нибудь более серьёзное и выложить где-нибудь в твиттере, реддите.
R>Microsoft полностью откажется от браузера Internet Explorer 15 июня 2022 года — спустя более чем 25 лет развития проекта. В официальном блоге Windows разработчики предупредили, что с окончательным прекращением поддержки ПО Interner Explorer 11 станет недоступно и прекратит работу на «определенных версиях Windows 10»
Интересует эти "определенные версии". Если зацепит клиента и заставит отказаться от IE (т.е. перевести их другие продукты на Edge/Chrome), то наш продукт конечно, выиграет. И уйдёт геморрой с поддержкой IE. Но что-то я сомневаюсь именно из-за оговорки про "определенные версии".
Здравствуйте, Тёмчик, Вы писали:
Тё>Я правильно понимаю, что сочетание Тё>const nativeElement=..... Тё>return ()=> {} Тё>Создает классическую циклическую ссылку, от которых в теории, GC и призван защищать?
Очевидно, что нет. GC гарантирует освобождение только тех объектов, что 1 сам размещает 2 сам контролирует ссылки.
Циклическую ссылку разрешить просто нечем.
Тё>Неплохо бы иметь какой-то статический анализатор кода, чтобы явно требовал занулить все ссылки на DOM после работы с ними.
Статический анализатор не справится, язык не обладает ссылочной прозрачностью.
Здравствуйте, Sheridan, Вы писали:
ES>>Есть немало серьезного ентерпрайза, у которого фронт на сервеладе. И никто переписывать его не спешит. S>Да, если в головах ветер немножко. А если с головами всё ок — то подобные апгрейды резерчатся, планируются, пишутся и внедряются.
Ога, я помню как ты на плюсах веб сайт писал ...
Ветер в голове ... Ну ну, в банках одни идиоты работают, и только ты гений
