Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, korvin_, Вы писали:
_>>Вот интересно, а что вы делаете в Java при получении OOM?
S>Смотря какой код у меня исполняется. Есть применения, где при получении OOM мне нужно не просто 500 Internal Error, а успеть сделать что-то полезное (например, сохранить стейт воркфлоу) перед тем, как умереть.

Это возможно только если под этот твой процесс сохранениня стейта уже была выделена вся необходимая для его работы память, что в языках с GC практически невозможно сделать, соответственно твоё "сделать что-то полезное" точно так же наткнётся на ООМ.

_>>А что вы предлагаете делать при OOM?
S>Много что можно сделать, особенно если озаботиться заранеешным созданием объектов, которые потребуются для обработки OOM. Например, можно урезать осетра и попробовать продолжить с буфером меньшего размера (хоть и медленнее).

Это в теории, на практике -- нет. Даже в С/C++ и прочих языках с "ручным" контролем памяти что-то сделать сложно. Поэтому приходит OOM-Killer

Поэтому на практике, что можно сделать: упасть. Гипервизор/оркерстратор перезапустит ноду/сервис/под/контейнер, а мы будем изучать логи, метрики, дампы, и по результату, либо добавим больше памяти, либо изменим параметры масштабирования, либо починим утечку, либо оптимизируем код.

_>>Это алгебраический тип, но при чём тут это?
S>То, что OOM могло бы быть одним из его слагаемых.

Так и что бы это дало? Как его использовать? Напиши пример.

_>>И что с ним делать в Expr? Давайте добавим. Как это отразится на expr0? Что вообще дальше делать с этим OOM?
S>Обрабатывать или прокидывать.
S>Ну, вот что нам делать с None в Optional<T>? Как замена int на Maybe<int> отразится на арифметике? Всё зависит от того, как сделан лифтинг в языке — автоматически, монадически, или никак.

Так Optional -- это другой тип по отношению к int. Теперь, сам Optional же тоже требует памяти, значит Optional<Optional<T>>, и для него тоже нужна память, Optional<Optional<Optional<T>>>, и так далее.

_>>Где бы он был в Java?
S>В Java он бы вылетел в виде unchecked exception. В воображаемой Java без исключений, но с not-nullable reference типами мы могли бы заставить new возвращать не T, а T?. В воображаемой Java с алгебраическими типами и наследованием мы могли бы заставить new T возвращать не T, а T | Error, и для общения с кодом, который требует чистый T этот результат пришлось бы очищать.

Так вот в Haskell/Ocaml и т.п. у нас нет new T, у нас сразу T, как 1, 2, true, false, "foo", "bar". Сразу значение.