Архитектура памяти: Erlang против Java

[braindamaged]

«за каждый день спектакля я считаю, что частная модель памяти кучи быть очень мощным инструментом в Erlang ящик «с. Она режет целые классы механизмы блокировки из системы во время выполнения и, что означает, что она будет масштабироваться лучше, чем Java будет с той же целью. Java-жесткие ограничения на память сохранить бекон, когда ваша система затопления или DDoSed.»

Made my day!

[Amper]

Извиняюст, случайно вставился лишний фрагмент ) Убрал )

[Amper]

* Извиняюсь
Да чтож такое )

[nuclear]

По-моему совсем не лишний. Отлично вписался.

[Masterkey]

красота!
немедля вернуть!

и меня немного ввело в ступор

>Мне кажется, что для Erlang-потока требуется около 512 байт. Для Java-потоков, как правило, необходимо около 512 килобайт, что примерно в 1000 раз больше.

может всетаки точно в 1024?

[Amper]

>Мне кажется, что для Erlang-потока требуется около 512 байт. Для Java-потоков, как правило, необходимо около 512 килобайт, что примерно в 1000 раз больше.

может всетаки точно в 1024?

Ну, в оригинале именно так… Тем более и там и там используется ОКОЛО 512… Видимо поэтому, ПРИМЕРНО в 1000 раз )

[Masterkey]

софистика

[naryl]

Нет. кило- — это ровно 10³.

[Masterkey]

вы на кибибайт намекаете?
не, я пока по старинке :)

да и в контексте статьи, с моей стороны, было неразумно прицепиться к этому мнимому несоответсвию.

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

[mixrin]

>выяснить как килять зажравшиеся процессы

Вы их не перекармливайте ;)

[kirilloid]

Их кормят злые анонимусы из ионной пушки ;-)

[erlyvideo]

Есть ровно два типа утечек памяти, требующих прибивания процесса:

1) невыгребание сообщений
2) накопление данных в состоянии процесса без их сброса

Других ошибок нет и быть не может by design. Долго и неоднократно обсуждали это в рассылке по эрлангу, но ни к чему внятному не пришли. Моё мнение — трекать процесс с максимально забитой памятью и в случае OOM, первым прибивать его. Дешево, практично и логично.

[mixrin]

512 кибибайт в 1024 раз больше 512 байт
512 килобайт в 1000 раз больше 512 байт

всегда ваша, матчасть

[mixrin]

Опции чтобы менять дефолтные значения, которые, как правило являются дефолтными.

[sunless]

TLAB — это чуть другое, это выделение памяти под объект без использования блокировок. Но это для объектов молодого поколения разумного размера.

[metronix]

можно приложить ссылочку и на саму дисертацию) www.it.uu.se/research/publications/lic/2005-001/

[CKOPOBAPKuH]

краткое содержание:

эрланг поток 512 байт java поток 1000 раз больше эрланг функциональный java общая куча эрланг куча каждому потоку много планировщиков очередь растёт память кончается машины подвисают

[netslow]

>Я выбираю Erlang в случае, когда нужна поток-ориентированная системы обмена сообщениями.
Как насчет Scala? Вроде бы она как раз совмещает в себе преимущества Java и, отчасти, Erlang, особенно если использовать вместе с Akka… Конечно это касается языка, виртуальная машина все равно jvm.

[b0n3Z]

А еще у нее более приятный синтаксис, что тоже немаловажно.

[mixrin]

Язык богаче и выразительнее, синтаксис потом будет.

[b0n3Z]

Вы про Эрланг? Когда будет? Дело в том, что ему уже больше двадцати лет и все никак.

[seriyPS]

Вон Elixir попробуйте если синтаксис уж совсем не нравится (хотя как по мне, то ничего так синтаксис, сносный)

[b0n3Z]

Очень круто, спасибо, обязательно попробую.

[seriyPS]

еще ссылочка habrahabr.ru/blogs/erlang/115372/

[Amper]

Ещё, кстати, есть Reia

[si14]

Может быть, со мной что-то не так, но почти во всём (кроме, разве что, доступа ко вложенным структурам данных — без синтаксического сахарка тяжеловато) мне эрланг больше питона нравится.

[mixrin]

Я читал наискосок, подумал что вы про скалу и джаву. :-)

Про синтаксис эрланга ничего особо не скажу, баловался несколько дней, ничего серьезного не писал. В принципе сносно, тем более что в своё прекрасная учительница в школе давала нам Пролог :-)

Конечно есть фанатики, орущие про ';', '.', ',', но это их удел. Синтаксис специфичен, но не более.

[bagyr]

У Акки не все хорошо с документацией и стабильностью, и почти нет эксклюзивных для jvm фишек. Ну и Эрланг это тоже не только много потоков и message-passing.

[stoune]

Если говорить о потоковости то Scala я так подозреваю переисспользует модель из Java.
Java уже проходила этап своих потоков, потому пришлось вернуться к native потокам.
У обоих моделей есть свои как плюсы так и минусы. Есть подозрение что если с этих Erlang потоков нужно обращение к ресурсам системы то большинство преимуществ будут потеряны.

[mixrin]

У Erlang VM есть отдельный пул потоков для i/o. Там с этим всё продумано, он создавался исключительно под нужды телекома.

[siasia]

Мне кажется, что статья предвзята. Автор анализирует, что плохого в нативном трэд мэнеджменте JVM при этом абсолютно игнорирую Akka, нацеленный как раз на реализацию микротрэдов из Erlang в JVM.

[erlyvideo]

1) это джава
2) когда её отладят и вылижут из неё хотя бы основную массу детских глюков, будет с чем сравнивать
Мой товарищ недавно нашел утечку памяти в unlink (!) скалы.
3) она _никогда_ не будет такой же стабильной в части использования памяти, потому что куча всё равно общая

[alexkolzov]

К вопросу об ожидаемой критике. Просто интересно. Почему вы считаете, что на функциональных языках нельзя писать реальные приложения?

[Amper]

Вопрос не ко мне, а к автору — я лишь перевел ) лично я функциональные языки обожаю. но к слову сказать, ведь «реальных» приложений на них действительно очень мало.

[alexkolzov]

Мало. Хотя это вопрос терминологии, что считать «реальным» приложением. Функциональные языки не особо востребованы в бизнес-сфере, что, по-моему, им только в плюс

[mixrin]

Это не мешает пользоваться функциональной парадигмой в «реальных» приложениях ;)

Буквально недавно начал нырять в функциональный Ruby, открыл для себя очень аккуратные ленивые списки :)

Вообще много где можно писать в функциональном стиле, надо просто знать как это хорошо делать в контексте используемого языка. Иногда получаются очень красивые решения.

[middle]

Семантика копирования, а не копирование семантики. ;)

[miolini]

Никто не упоминул о таком свойстве JVM, как невозможность возвратить ядру операционной системы страниц памяти, если они больше не нужны — JVM в течении жизни процесса умеет только расти. Erlang это умеет возвращать.

Это очень актуально в облаках, когда оперативная память выделяется по необходимости.