ErlyBird 0.15.1

> А где провести эту черту, если по логике работы программы все значения пожирания памяти от 10мб до 1.5гб равновероятны и зависят от исходных данных?

"Если у бабушки был бы х*й, то это был бы дедушка". Пожалуйста, реальный пример в студию. Уверен, что в реальном случае можно найти достаточно способов обойти то что вы говорите, если задача не совсем абсурдна. А иначе, вам же ясно сказано, профайлер, дебаггер в руки и вперед.

> Где провести ту грань, после которой я должен запускать мусорщика?

Верите, за ~ 3 года работы с Java'ой, кажется не разу не озаботился насчет сборщика мусора, ибо не нужно было. Просто нужно писать правильный код, закрывать культурно ресурсы где надо и не будет проблем.

>"Если у бабушки был бы х*й, то это был бы дедушка". Пожалуйста, реальный пример в студию. Уверен, что в реальном случае можно найти достаточно способов обойти то что вы говорите, если задача не совсем абсурдна. А иначе, вам же ясно сказано, профайлер, дебаггер в руки и вперед.


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

> А где провести эту черту, если по логике работы программы все значения пожирания памяти от 10мб до 1.5гб равновероятны и зависят от исходных данных? Где провести ту грань, после которой я должен запускать мусорщика?

Не нужно вручную запускать мусорщик. Выдели программе правильный объём памяти, а gc пусть запускает runtime в нужные ему моменты времени.

Ну вот объясните мне, зачем освобождать эту память? Чтобы циферки в top были красивые? Всё равно неиспользуемая память рано или поздно выдавится в swap и не будет расходовать физическую память.

>> А где провести эту черту, если по логике работы программы все значения пожирания памяти от 10мб до 1.5гб равновероятны и зависят от исходных данных? Где провести ту грань, после которой я должен запускать мусорщика

> Навскидку (точно не уверен!): Long maxMemory = Runtime.getRuntime().maxMemory(); Long totalMemory = Runtime.getRuntime().totalMemory(); if (totalMemory>(0.75*maxMemory)) { System.gc(); } Либо пронализировать какие исходные данные приводят в отжиранию полутора гигов.

Куда пропала понятность кода? Где тот самый лозунг, что программист не должен заботиться об освобождении памяти? Закон дырявых абстракций таки рулит :)

> Ну вот объясните мне, зачем освобождать эту память?

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

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

Реализация стандартной подпрограммы sort на жаве. Видим явную зависимость потреблённой памяти от входных данных. Если добавить к этому ещё какую-либо статистическую обработку данных, то получим то, на чём описанная проблема может аукнуться.

Единственные вменяемы люди в этом топике - это gaa и некоторые из anonymous'ов. Все остальные кто нахваливают яву либо ей не пользовались, либо не дружат с мозгом. Особенно понравилось последнее высказывание одного умника про то что пусть лучше в своп полезет чем память отдать

>Куда пропала понятность кода? Где тот самый лозунг, что программист не должен заботиться об освобождении памяти? Закон дырявых абстракций таки рулит :)

Пока не будет создан ИИ машина никогда не сможет управлять памятью идеально, сборщик мусора рулит на равномерных нагрузках. Откуда JVM, может знать будете ли вы использовать потом полтора гига выделенной памяти или вам достаточно 10 метров, вот поэтому и не происходит мгоновенного освобождения.

> Пока не будет создан ИИ машина никогда не сможет управлять памятью идеально, сборщик мусора рулит на равномерных нагрузках. Откуда JVM, может знать будете ли вы использовать потом полтора гига выделенной памяти или вам достаточно 10 метров, вот поэтому и не происходит мгоновенного освобождения.

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

> Единственные вменяемы люди в этом топике - это gaa и некоторые из anonymous'ов.

Льстец =:)

>JVM _знает_, что эта память мне не нужна. Я специально освобожу все ссылки на неё. Н принцип работу мусорщика, описанный выше, сохранится.

Хотите другое поведение сборщика - использутей Java Real Time VM (кажется так называется), там ведется постоянный учет количества ссылок.

>Объясняю. Реальный рабоыий пример: создаётся куча мелких объектов, причём памяти на них заведомо не хватает.

Это в каком Use case приходится создавать кучу мелких объектов? Может из базы данных их тянете, чтобы в JVM отсортировать и отфильтровать? А слова WHERE и SORT BY незнакомы?

>Пока не будет создан ИИ машина никогда не сможет управлять памятью идеально, сборщик мусора рулит на равномерных нагрузках

гы. так в питоне тоже есть мусоросборщик. его нет только в чихпыхе потому что чихпыху он не нужен - там всё с нуля каждый запрос. да и то есть наверно - чихпых же и консольный бывает.

можно конечно два дня сидеть в gdb, следить куда 10 байт убегают при каждом вызове процедурки, потом найти что виновата какаянить libxml и сильно ругаться. но это всё хуман-ресурсы.

>> Объясняю. Реальный рабоыий пример: создаётся куча мелких объектов, причём памяти на них заведомо не хватает.

> Это в каком Use case приходится создавать кучу мелких объектов? Может из базы данных их тянете, чтобы в JVM отсортировать и отфильтровать? А слова WHERE и SORT BY незнакомы?

Слова знакомы, use case не такой.

>> JVM _знает_, что эта память мне не нужна. Я специально освобожу все ссылки на неё. Н принцип работу мусорщика, описанный выше, сохранится.

> Хотите другое поведение сборщика - использутей Java Real Time VM (кажется так называется), там ведется постоянный учет количества ссылок.

А переопределить поведение мусорщика, не перелезая на другую редакцию JVM можно?

>А переопределить поведение мусорщика, не перелезая на другую редакцию JVM можно?

В Java 6.0 используется несколько стратегий поведения GC.

1. Вводная статья: http://www.ibm.com/developerworks/ru/library/j-jtp11253/index.html

2. Сборка мусора и производительность: http://www.ibm.com/developerworks/ru/library/j-jtp01274/index.html

>> А переопределить поведение мусорщика, не перелезая на другую редакцию JVM можно?

> В Java 6.0 используется несколько стратегий поведения GC.

Спасибо, почитаем-с...

> Всё равно неиспользуемая память рано или поздно выдавится в swap и не будет расходовать физическую память.

Просто превосходно сказано. Автор гениально ставит крест на самой идее освобождения памяти, доказывая ее ненужность. Правда, пока лишь в userspace, но уверен что и на kernelspace можно будет замахнуться в будущем! Главное не бояться, понимаешь, авторитетов.

Я предлагаю эту фразу внести в учебники по программированию.

>> Всё равно неиспользуемая память рано или поздно выдавится в swap и не будет расходовать физическую память.

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

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

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

Сам подумай. Есть ли в Windows распределённый своп, чтобы туда писали несколько машин в сети. Кластеры, говорите? Ну-ну. :))

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

> Сам подумай. Есть ли в Windows распределённый своп, чтобы туда писали несколько машин в сети. Кластеры, говорите? Ну-ну. :))

Не понял, по какому вектору меня отправляют думать.

>у Visual Studio возможностей на порядок больше, а требования меньше

Вызывающе неверная информация

>приходится лазить в кучу справочников и примеров ибо нормальный человек >строку <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" >"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; >; ни в жизни >не запомнит, а главное не будет набивать с нуля. вот я и лезу в мануалы >и примеры. а у него редактор сам всё вставляет без понтов.

apt-get install screem

(screem - A GNOME website development environment)

Клацаешь <<Новый документ>> появляется Друид вводишь - имя файла - папку - тип документа - выпадающий список (та фигня что ты указал) - кодирофка Жмеш далее появляется 2 страница Друида вводишь - title - author - keywords - description Жмеш далее появляется 3 страница Друида выбираешь * не юзать темплейт * юзать стандартный темплейт * юзать custom темплейт

Жмеш далее появляется 4 страница Друида выбираешь - файл CSS - задаешь дефолт цвета - задаёш бэкгроунд

Жмеш финишь

>А глаза у меня зеленые.

Мутант?

>> А глаза у меня зеленые.

> Мутант?

Это кот. Пока shahid отошёл попить чаю, кот пробрался к компу и начал флудить :)

> Значит ява пригодна только для создания IDE?

When I met Java some time ago, I said to myself: "Java is a great language to write IDEs for the Java language".

Now that I'm looking for Haskell source code (perhpas that there is another way to learn a language than to spy on others?), I'm tempted to say: "Haskell is a great language to write libraries for the Haskell language"

(C) Haskell Cafe

"...the only thing people do with ML is to make ML compilers"

(C) Brian Kernigan

>есть tomcat - костыль к апачу для выполнения сервлетов и все.

Если ты его так пользуешь - твои половые трудности.

>Возьмем ftp сервера - тоже нету.

http://incubator.apache.org/projects/ftpserver.html

> Active Directory - тут тоже никакой жабы.

http://directory.apache.org/

Читайте гугл - там все написано.

>Опять же является основной, но примеров нету, а сами Oracle и DB2 написаны не на яве

У оракла в потрохах Aurora JVM - а как он по твоему исполняет сторед проци на жабе? Их линейка продуктов как и бимеров основана на жабских технологиях. Немаленький сайт бимеров и OTN тоже на жабе - очень немаленькие проекты. OTN на Oracle Portal Server - насколько я понимаю они саме первые перелезли на собственный портал показав что они не фирмочка которая продают за мегабабки солюшены а сама сайт на пыхе держит - я еще помню как вначале у них некоторые портлетики падали.

Короче если не знаешь - учи гугл хотя бы.

>жаба по умолчанию отжирает гигабайта полтора минимум.

К вам инопланетяне по ночам не ходяд?

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

ТАм есть свои игры с "а чья операционка?". Nokia,Sony/Eric - Symbian, Motorola c маниакальным упорством ставит линуксы, а потом не выпускает мобилы (хочу ROKR E7! или хоть E6 - де взять?) все остальные платят микрософту.

>Давайте сравним C и Java на числодробилке, для которой Java не предназначена

ТЫ на апачах числодробилки пишешь? Или на питоне? А может на руби?

>А снаружи наблюдается подвисание на ~ 20 минут, а затем OutOfMemoryException. Это приемлимое поведение?

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

>А переопределить поведение мусорщика, не перелезая на другую редакцию JVM можно?

use java -X luke

>Нахера было делать это, а не складывать в памяти, которую система сунет в своп, непонятно.

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

>Не понял, по какому вектору меня отправляют думать.

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

>> А снаружи наблюдается подвисание на ~ 20 минут, а затем OutOfMemoryException. Это приемлимое поведение?

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

Во-первых, не фантазия. Во-вторых я хочу сразу получить сообщение о нехватке памяти, а не кудрячить бокра, пока до менеджера памяти это не дойдёт.

>> Не понял, по какому вектору меня отправляют думать.

> По пектору поднятия бина в физически другой машине, после краша и других подобных мелочей.

Спасибо, добрый человек, объяснил. Теперь я вник.

>Во-вторых я хочу сразу получить сообщение о нехватке памяти, а не кудрячить бокра, пока до менеджера памяти это не дойдёт.

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

> Напиши простой тест - увидишь.

Тест:

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);
}
}
}
}

Если закомментировать строчку "list.remove(0);"

$ time /usr/lib/jvm/java-6-sun-1.6.0.00/bin/java -Xmx1M Main
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2760)
at java.util.Arrays.copyOf(Arrays.java:2734)
at java.util.ArrayList.ensureCapacity(ArrayList.java:167)
at java.util.ArrayList.add(ArrayList.java:351)
at Main.main(Unknown Source)

real 0m0.155s
user 0m0.134s
sys 0m0.013s

Раскомментировал:

$ time /usr/lib/jvm/java-6-sun-1.6.0.00/bin/java -Xmx1M Main
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2760)
at java.util.Arrays.copyOf(Arrays.java:2734)
at java.util.ArrayList.ensureCapacity(ArrayList.java:167)
at java.util.ArrayList.add(ArrayList.java:351)
at Main.main(Unknown Source)

real 3m32.284s
user 3m24.952s
sys 0m0.195s

Вот именно такое поведение мне не нравится. Было б время больше только в 2 раза, я бы был спокоен. А тут в полторы тыщи раз больше!

> Вот именно такое поведение мне не нравится. Было б время больше только в 2 раза, я бы был спокоен. А тут в полторы тыщи раз больше!

Знаю, что во втором варианте алгоритм слегка не соответствующий, но всё же он уж такое торможение дать не может.

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

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

>хочу ROKR E7! или хоть E6 - де взять?

Если в Киеве (судя по "Информация о пользователе r"), то я брал в апреле ROKR E2 в Евротел (http://www.evrotel.info/), там же и E6 были.

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

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

> Н вполне может возникнуть ситуёвина, схожая с описанной в примере.
В нашей жизни все может произойти и ожидать, что на все будет ответ (серебряная пуля) несколько наивно.

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

К счастью JVM позволяет выбирать ту или иную схему работы GC вплодь до его отключения.

Когда в одном из моих проектов возникла похожая ситуевина (редкие команды отжирали 2Gb и потом приложению на неск. часов вперед было достаточно 100Мб...
Просто для этой задачи "отпочковывается" отдельная JVM в рамках которой выполняется объемная работа. Затем этот JVM спокойно умерает отдавая оперативную память.

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

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

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

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

> Когда в одном из моих проектов возникла похожая ситуевина...

Интересный метод, приму на заметку.

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

> Интересный метод, приму на заметку.
Пожалуйста. Спрашивайте еще. :)

>Сам подумай. Есть ли в Windows распределённый своп, чтобы туда писали >несколько машин в сети. Кластеры, говорите? Ну-ну. :))

А где есть распределенный сетевой своп ? И какое отношение Java Beans имеют к Windows ?

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

>о я брал в апреле ROKR E2 в Евротел (http://www.evrotel.info/), там же и E6 были.

ooo!! great tnx!

А блин - ни одна фирма не листится где есть. Та шож такое.