ErlyBird 0.15.1

>это по сути обход огроменной дыры в абстракции управляемой памяти.

Абстракция неуправляемой памяти такая же самая, разве что вы уженацчились предсказывать время осводжения неизвестного дерева объектов и суперджефрагментирующий деаллокатор написали - как там FF полечили?

>Кхм, а как же лозунг "програмист не должен заботиться об освобождении памяти"?

в 99% случаев он и не заботится. Мало?

>> это по сути обход огроменной дыры в абстракции управляемой памяти.

> Абстракция неуправляемой памяти такая же самая, разве что вы уженацчились предсказывать время осводжения неизвестного дерева объектов и суперджефрагментирующий деаллокатор написали - как там FF полечили?

Почему я, не замешанный в написании FF, должен его лечить? Пусть им mozilla corp занимается.

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

>> Кхм, а как же лозунг "програмист не должен заботиться об освобождении памяти"?

> в 99% случаев он и не заботится. Мало?

Просто про оставшийся процент частенько забывают, а потом удивляются: "а что это оно так много памяти скушало?"

2gaa - не корми троля, плз.

> Просто про оставшийся процент частенько забывают,...
Даже "частенько" для оставшегося процента редкое событие. При программировании вообще о памяти забывать вредно безотносительно используемого языка.

>NFS?

NFS для системного свопа ? А не жирно ли будет ? Кстати , NFS client есть и для Windows . Или мы говорим о "свопе" для Java Beans ?

>Там есть такая вещь как выкидывание неиспользуемых entity bean-ов в некоторое подобие свопа. То есть bean сериализуется и записывается на диск а потом, при необходимости считывается и десериализуется. Нахера было делать это, а не складывать в памяти, которую система сунет в своп, непонятно.

Если Вы ответите себе, почему браузер складирует страницы и картинки в кеш, а не в своп, Вам и здесь станет многое понятно :-) Безотносительно java. Я её не использую.

> Если Вы ответите себе, почему браузер складирует страницы и картинки в кеш, а не в своп, Вам и здесь станет многое понятно

да мне уже подсказали. может пример с браузером и некорректен, но всё равно спасибо

>> А где есть распределенный сетевой своп ?

> NFS?

Lustre?

Лучше вот что скажите.

Sun completed its acquisition of Cluster File Systems, Inc., including the Lustre file system, on October 2, 2007 with the intention of bringing its technologies' benefit to Sun's ZFS file system and the Solaris operating system.

ZFS не совместима с GPL. Однако, Lustre - под GPL. Каким образом? Сделают ZFS GPL-совместимой?

> Кхм, а как же лозунг "програмист не должен заботиться об освобождении памяти"?

А можно ссылку на оригинал лозунга? А то мне почему-то кажется, что там не "не должен", а "не обязан", в том смысле, что это не должно волновать его _постоянно_.

> Тест:
>
> import java.util.*;
>
> class Main{
>
> public static void main( String[] args ){
> List<String> list=new ArrayList<String>();
> int i=0;
> while (true) {
> String s="1";
> list.add(s);
> i++;
> if (i>100 && i%2==1) {
> list.remove(0);
> }
> }
> }
> }

Запускать не пробовал, но - не верю. Есть такое понятие, как "пул строк", и все строки, фигурирующие в командах ldc в байт-коде, там быть обязаны. Поэтому код экивалентен следующему:

List<String> list=new ArrayList<String>();
int i=0;
String s="1";
while (true) {
list.add(s);
i++;
if (i>100 && i%2==1) {
list.remove(0);
}
}

>Запускать не пробовал, но - не верю. Есть такое понятие, как "пул строк", и все строки, фигурирующие в командах ldc в байт-коде, там быть обязаны. Поэтому код экивалентен следующему:

Между этими двумя примерами есть большая разница

1. В каждый элемент листа загоняется новое значение (создаётся новый объект) 2. В каждый элемент листа загоняется референс на один и тот же объект (память отжирается только на референс)

В первом случае алгоритм очень плохой. Надо просто посчитать сколько памяти надо по максимуму и проставить соответствующий -Xmx ключик.

Кстати, это типичный пример как НЕ надо программировать на Javа. Если есть функциональные требования то в студию, а такие примеры фтопку.

List<String> lst = new ArrayList<String>(); for (int i = 0; i < 2; i++) { String s = "1"; lst.add(s); } System.out.println(lst.get(0) == lst.get(1));

true

Проверено в JDK5.

Из javadoc-а к String#intern():

A pool of strings, initially empty, is maintained privately by the
class <code>String</code>.
When the intern method is invoked, if the pool already contains a
string equal to this <code>String</code> object as determined by
the {@link #equals(Object)} method, then the string from the pool is
returned. Otherwise, this <code>String</code> object is added to the
pool and a reference to this <code>String</code> object is returned.

All literal strings and string-valued constant expressions are
interned.

>true

В этом частном случае, да. Но это только для стрингов. В реальной жизни через == сравнивают по референсам а по value сравнивают через .equals метод.

>A pool of strings, initially empty, is maintained privately by the class <code>String</code>.

У этого пула есть максимальный размер. Когда количество объектов превысит определённый порог, пул будет выбрасывать елементы (скорее всего по LRU алгоритму)

Вот так будет правильнее

public static void main(String[] args) { List<String> lst = new ArrayList<String>(); for (int i = 0; i < 2; i++) { String s = new String("1"); lst.add(s); } System.out.println(lst.get(0) == lst.get(1)); }

false

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

Слегка модифицировал код, чтоб быстрее вываливалось

List<Integer[]> list = new ArrayList<Integer[]>();
int i = 0;
Long t = new Date().getTime();
try
{
	while (true) {
		Integer [] s = new Integer[1000];
		list.add(s);
		i++;
		if (i > 100 && i % 2 == 1) {
			//list.remove(0);
		}
	}
}
catch(OutOfMemoryError e)
{
	System.out.println(new Date().getTime() - t);
}

без remove: 63ms

c remove: 297ms

Вроде не так страшно

В случае со стрингом с remove - 25235 без remove - 125

Странно все это... В профайлере его прогнать, что ли?

Все дело в имплементации remove метода в LinkedList и ArrayList. В ArrayList remove(0) намного медленнее, поэтому и вываливается намного медленнее так как требуется переразмещение памяти на каждый remove.

В случае со стрингом 
LinkedList
с remove - 254770 1235
без remove - 127435 234
ArrayList
с remove - 397056 25235
без remove - 198578 125

PS первая цифра в результате - это количество эелементов в массиве

Если ананизмус не видел ынтерпрайз системки на жабе. Например такие, которые разрабатывает Sabre и IBM, это не значит что примеров нет.

Просто ананизмус дальше своего ночника powered by пыхпых & мускуль не заглядывал.

> Все дело в имплементации remove метода в LinkedList и ArrayList. В ArrayList remove(0) намного медленнее, поэтому и вываливается намного медленнее так как требуется переразмещение памяти на каждый remove.

Ну уж если доведёте до разницы не более чем в 3 раза, тогда перестаю катить бочку на жабный менеджер памяти. А так всё равно многовато...

>ZFS не совместима с GPL. Однако, Lustre - под GPL. Каким образом? Сделают ZFS GPL-совместимой?

Зачем? Они же купили ее, а не лицензировали под GPL. А CFS ей владеет - то есть может раздавать как хочет. Хоть под MSEULA. Теперь ею владет Sun и он же будет определять лицензионную политику.

> Для избежания создания большого количества объектов есть несколько паттернов.
В частности, наиболее используемые это Object pool и Reuse object.
Ими покрывается наверное процентов 80 потребностей и реально экономят ресурсы.

> Другой вариант - использование отложенных вызовов (lazy).


зачем тогда java ?

>Ну уж если доведёте до разницы не более чем в 3 раза, тогда перестаю катить бочку на жабный менеджер памяти. А так всё равно многовато...

1235/234=5.2(7) - для LinkedList.

А ты посмотри в дебаггере, что происходит при удалении и подумай, что лучше, потерять немного производительности (опять повторю, алгоритм сакс) или иметь проблеммы с Buffer Overflow?

Посмотри другие имплементации Collection, может они будут быстрее.

>>Ну уж если доведёте до разницы не более чем в 3 раза, тогда перестаю катить бочку на жабный менеджер памяти. А так всё равно многовато...

> 1235/234=5.2(7) - для LinkedList.

3 < 5

> А ты посмотри в дебаггере, что происходит при удалении и подумай, что лучше, потерять немного производительности (опять повторю, алгоритм сакс) или иметь проблеммы с Buffer Overflow?

Алгоритм специально и писался "саксово", чтобы показать "саксовость" менеджера памяти. А причём тут Buffer Overflow я не понял.

>Алгоритм специально и писался "саксово", чтобы показать "саксовость" менеджера памяти. А причём тут Buffer Overflow я не понял.

Я тоже могу написать саксовый алгоритм на C и он будет работать хуже, чем на жаве. Тебе нужно понять ПОЧЕМУ алгоритм работает медленно и переписать его так, чтобы он быстро работал.

А Buffer Overflow это то, что может получится если переписать этот код с жабы на С и использовать массивы.

Кстати я почти уверен если ты перепишешь его на С с массивами, то результаты будут близки, если не хуже, чем на жабе с ArrayList

>> Алгоритм специально и писался "саксово", чтобы показать "саксовость" менеджера памяти. А причём тут Buffer Overflow я не понял.

> Тебе нужно понять ПОЧЕМУ алгоритм работает медленно и переписать его так, чтобы он быстро работал.

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

> А Buffer Overflow это то, что может получится если переписать этот код с жабы на С и использовать массивы.

Если руки кривые, то из всего можно сделать buffer overflow...

> Кстати я почти уверен если ты перепишешь его на С с массивами, то результаты будут близки, если не хуже, чем на жабе с ArrayList

Не получится. Потому что результатом должна стать плохая работа менеджера памяти при её почти полном исчерпании, связанная со сборкой мусора и дефрагментацией. В си этого по определению нет, т.к. там нет сборки мусора и дефрагментации.

>Просто для этой задачи "отпочковывается" отдельная JVM в рамках которой выполняется объемная работа. Затем этот JVM спокойно умерает отдавая оперативную память.

Это как такое делать? Из-под JVM запустить другую JVM? Какой командой?

> Из-под JVM запустить другую JVM? Какой командой?

exec() вестимо... то бишь запустить как обычную внешнюю программу

> Объясняю. Реальный рабоыий пример: создаётся куча мелких объектов, причём памяти на них заведомо не хватает. Что делает менеджер памяти, когда память подходит к концу? Правильно, запускает сначала уборку мусора, потом дефрагментацию и повторяет это снова и снова. А снаружи наблюдается подвисание на ~ 20 минут, а затем OutOfMemoryException. Это приемлимое поведение?

Это выбран неправильный тип gc.

>В си этого по определению нет, т.к. там нет сборки мусора и дефрагментации.

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

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

Да. И _свой_ менеджер памяти будет гораздо более эффективен на конкретной задаче, чем вездеходы, что насованы в жаббу. Просто потому, что он специализированный.

> Да. И _свой_ менеджер памяти будет гораздо более эффективен на конкретной задаче, чем вездеходы, что насованы в жаббу.

Только сколько сил и времени нужно будет потратить на написание _своего_ менеджера памяти. Довести его до production состояния, принудительно заставить им пользоваться других разработчиков в проекте.
Следить, чтобы никто в обход не работал.

В итоге получив несколько большую скорость проект сильно просядет по времени и стоимости.