J
Теперь понимаю почему отчасти пыхокодеры писали императивную лапшу вместо кода с нормальной модульностью. Дизайн самого (дефолтного) интерпретатора подталкивал к такому если не хотелось утечек памяти.
Size: a a a
2021 January 07
IP
Теперь понимаю почему отчасти пыхокодеры писали императивную лапшу вместо кода с нормальной модульностью. Дизайн самого (дефолтного) интерпретатора подталкивал к такому если не хотелось утечек памяти.
эм, так там, начиная с 5.3, нормальный гц
IP
даже cyclic reference можно :)
J
Я о ранних версиях Пыха
AK
Теперь понимаю почему отчасти пыхокодеры писали императивную лапшу вместо кода с нормальной модульностью. Дизайн самого (дефолтного) интерпретатора подталкивал к такому если не хотелось утечек памяти.
Думаю, что знатное множество описываемых вами «пыхокодеров» даже и не слыхало про какие-то утечки, а «императивную лапшу» писали потому, что это был их уровень
J
Ну ранний php development состоял из Си-шников которые писали CGI скрипты. Они про утечки памяти должны были знать.
AK
Кроме того, насколько я помню, ранние версии запускали по отдельному процессу на каждый запрос, который отрабатывал и сразу же умирал. Поэтому сделать существенную утечку памяти было довольно сложно
AK
Ну ранний php development состоял из Си-шников которые писали CGI скрипты. Они про утечки памяти должны были знать.
PHP - for amateurs, by amateurs (c)
J
Кроме того, насколько я помню, ранние версии запускали по отдельному процессу на каждый запрос, который отрабатывал и сразу же умирал. Поэтому сделать существенную утечку памяти было довольно сложно
Ну монструозные приложения (вроде цмс-ок и админок всяких) от этого уже страдали. Так что всякие Реакты которые сейчас любят критиковать сторонники старой школы, выглядят вполне себе инструментами с хорошей оптимизацией.
J
Кстати в Перле тоже не чистится память от локальных переменных по завершению скоупа.
AT
Кстати в Перле тоже не чистится память от локальных переменных по завершению скоупа.
Как и в Java/C#/Haskell и любом другом языке с GC. 🤷♀️
J
Не. В Жабе и Шарпе чистятся stack allocated (по завершению функции) и heap allocated data (если на нее нет ссылок).
J
В модели памяти Перла и Пыхи до 5.3 версии как выяснили, даже таких понятий не существует. Все параметры и локальные переменные аллоцируются в символьных таблицах которые аллоцируются при каждом вызове функции. И чистится все при завершении скриптового процесса.
AK
Не. В Жабе и Шарпе чистятся stack allocated (по завершению функции) и heap allocated data (если на нее нет ссылок).
Размещенные на стеке данные сложнее сохранить, чем удалить при выходе из скоупа
J
Да. Для работы со случаями, когда данные аллоцированные на стеке могут использоваться после завершения скоупа, существует escape analysis как в JIT Java и Go
AK
Имхо, мы немного о разных вещах говорим. В сишарпе, например, есть специальная фича (
stackalloc), которая явно говорит: "вот это нужно разместить на стеке". На нее накладываются существенные ограничения, поэтому использовать данные после завершения скоупа принципиально нельзя. А вот если JIT по собственной инициативе пытается что-то разместить на стеке ради оптимизации - там, да, нужен escape analysisM
там ограничения скорее из-за того что нельзя в работающей аппе поменять вообще всё, оно просто патчит вызовы функций, но запатчить многое другое нельзя - например удалить переменную сложно если в нее кто-то лазит в живом коде
Можно, просто нужен интерпретатор или джит
DP
как можно делать песочницу для кода?
например, берем плохой код котооый содержит прыжок к далекой памяти за пределами кода или прыжок на себя же для бесконечного цикла.
как можно написать код-песочницу который гарантирует что плохой код будет обработан и завершиться через конечное время? (например 1000 инструкций). и что он не изменит память вне песочницы
например, берем плохой код котооый содержит прыжок к далекой памяти за пределами кода или прыжок на себя же для бесконечного цикла.
как можно написать код-песочницу который гарантирует что плохой код будет обработан и завершиться через конечное время? (например 1000 инструкций). и что он не изменит память вне песочницы
VK
как можно делать песочницу для кода?
например, берем плохой код котооый содержит прыжок к далекой памяти за пределами кода или прыжок на себя же для бесконечного цикла.
как можно написать код-песочницу который гарантирует что плохой код будет обработан и завершиться через конечное время? (например 1000 инструкций). и что он не изменит память вне песочницы
например, берем плохой код котооый содержит прыжок к далекой памяти за пределами кода или прыжок на себя же для бесконечного цикла.
как можно написать код-песочницу который гарантирует что плохой код будет обработан и завершиться через конечное время? (например 1000 инструкций). и что он не изменит память вне песочницы
Нативный или байткод?