К тому, что OOM Java вырубит напрочь, как и Linux. Разумеется, никто с этим спорить не будет.

AFAIK изолироваться по ошибкам памяти можно только:

1. Выносить вычисления из потоков в процессы. Тогда падает процесс, остальные продолжают работать. Но тогда, обычно, проигрываем в производительности.

Но проблема не исчезает, а просто уходит на след. уровень операционной системы. Т.к. подвесить и весь Linux тоже можно. Может ли системный администратор грамотно настроить Linux, что бы процессы гарантированно не вешали ядро - думаю что да.

2. Какие-то средства на уровне языка / выполняющей среды. Позволяющие контролировать потоки по потреблению памяти. В Java к огромному сожалению, я такого не знаю. Почему не сделано - я не знаю, т.к. лично мне, этого явно не хватает.

Более интересный вопрос, что может предложить JavaScript, что бы решить эту проблему. А вот эта тема не раскрыта. Если в JavaScript'е есть возможность отдельным функциям вешать лимит по потребляемой памяти - тогда да, но подозреваю, там такого нет.

А вот действительно, почему бы в Java не добавить простой механизм:

Для каждого потока считаем кол-во выделенной памяти в eden
При minor GC, при очистки памяти, уменьшаем этот счетчик
При переносе в Tenured, где-то храним Id исходного потока

Должно достаточно легко делаться, т.к. и так в enen своя отдельная область для потоков нарезана.

Т.е. подсчитываем память выделенную потоком в Old Gen

Почему бы, не давать возможность задавать лимит на поток, для выделения в Old Gen? Если поток (+порожденные им потоки) лимит превысил - тупо прибиваем.

Это не средство программиста, а средство АДМИНИСТРАТОРА.

Один сервер (WebLogic), одно JVM, много приложений, десяток программистов

Один программист сделал ошибку/опечатку, банальный вечный цикл. Потребление памяти ушло в бесконечность. Одна опечатка - а погиб весь сервер.

maytonЧаще всего OOM возникает в силу ошибок в приложении. И эти ошибки надо исправлять
а не отстреливать потоки. Такая архитектура будет слишком ненадежной и неочевидной.
Мрут потоки. Почему - неясно.
IMHO
I.1.
СНАЧАЛА надо отстреливать потоки. Что бы ошибка НА РАСПРОСТРАНЯЛАСЬ дальше на весь сервер и не ломала то, что работает без ошибок.
I.2.
Потом исправлять ошибки.

II. Как раз будет очевидно. Пришел HTTP запрос такой-то, был сброшен, т.к. превысил лимит по памяти - где ошибка, совершенно понятно, легко тестировать. Сейчас все хуже, сервер стоит колом но все вроде работает, где ошибка - фиг поймешь.

При этом, отстрел потоков по timeout'у существует, если поток долго считает 2+2 - его сервер пристрелит. Просто дополнительно нужен отстрел по памяти.

Проблема в App Server'ах. Разные приложения от разных программистов выполняются в одном адресном пространстве ((( Вроде даже существует изоляция кода друг от друга на уровне Class Loader'а, но для изоляции друг от друга на уровне Heap'а и OOM - нет ничего.

Проблема не в том, что ошибочный код падает. Проблема в том, что вместе с ним может упасть и другой, полностью работоспособный код.

P.S.
Человек разрабатывал программы для электростанций. В поставки идет шкаф, где у каждого отдела СВОЙ физический компьютер (или даже несколько). И пофиг на то, что ресурсы используются на 1 %. Главное, что если будет сбой - то нет возможности перевалить ответственность на другого/другой отдел. Т.к. ошибки могут привести и к уголовно наказуемым последствиям.

Существующая реализация приложений в app server'ах - полностью ублюдочный. В основном, за счет отсутствия хоть какой-то изоляции и классов и приложений по памяти и OOM. IMHO

Но боюсь, в node.js ничуть не лучше. Если там есть какие-то крутые решения, буду рад о таком услышать.

забыл никДа нету никакого в этом смысла имхо, или я не уловил мысль.

Попытка хоть какое-то осмысленное "лимита на память" для Web.

К сожалению "лимит на память" вряд ли получится, но "лимит на выделение памяти" сделать можно.

Как программист / администратор, я могу примерно сказать, какое потребление (в том числе и выделение) памяти у моего кода в "штатном" режиме. Если код переходит в "нештатный режим" (например попали в вечный цикл) - грохаем.

Понятно, что для рабочего варианта нужно дорабатывать напильником. Все потоки разные, грести всех под одну гребенку - не есть айс, на Web-сервере - запросы разные, а выполняются в одном потоке (из пула), тоже грести всех под одну гребенку - не есть айс. Но хоть как-то задавать лимиты по памяти, жизненно необходимо. IMHO

забыл никЕсли код ваш - то вы как девелопер должны нести отвественность за каждый поток, и в случае чего должны тюнить и фиксить.

Дивелопер и "нести ответственность" ))) IMHO понятия не совместимые )))
+
В фирме могут быть 100-ни дивелоперов
забыл никлучше всего запускать в отдельной JVM или виртуалке.

Не спорю. Сам сейчас так и делаю. Проект побит по модулям, каждый модуль на своей JVM, общаются через RMI.

Перезапуск отдельного модуля на остальные не сказывается (подхватывается на лету).

Mad_HeadМне лично JS нравится\

То, о чем я раньше и говорил.

Java & Java Script - это два совершенно разных языка. Технически, вряд ли кто будет спорить, что и то и то решение сейчас рабочее . Масса проектов и на одно и на другом

Т.ч. самый важный критерий выбора - кому что нравится.

Вот лично я, на скриптовых языках без типизации программировать отказываюсь. Лучше уж пойду бомжевать и попрошайничать, чем буду унижать себя программированием на этом отстое ))). А кто -то наоборот )))

А примерно о том же, _работающих_ языков как грязи. Кому что выбрать - в 90% вопрос личного предпочтения.

Будет ли проект успешный и будет ли код высокопроизводительным - на 90% зависит от прямых рук исполнителя и лишь на единицы процентов - от выбранного средства разработки.

IMHO & AFAIK