Спасибо! Вторая ссылка избавит от необходимости использования iGoogle. Жаль только, что не сохраняет последнее состояние, как одноимённый портлет в iGoogle, открывая всегда Default List.
Надеюсь, они не закроют теперь Google Tasks :)
Я использую iGoogle преимущественно для Google Tasks, причём насколько я знаю только в нём можно развернуть задачи на весь экран, никакой другой веб-сервис такого сделать с задачами в учётной записи Google не даёт.
Жаль, что такой возможности больше не будет. Но зато это готовая идея для чьего-то стартапа :)
Согласен, чудесное приложение.
Очень жду появления веб-интерфейса к этому. Такого же красивого, как айфон-версия.
А то иначе желание пополнять отпадает, не с кем поделиться красотой :)
Меня тоже порадовало :)
Как заявил представитель Red Hat, в их интересах обеспечить поддержку JBoss Application Platform. Более того, интереснее всего сделать плагин универсальным, дав возможность использовать его не только для одной платформы.
Тут хочется сказать Google большое спасибо.
Забавно, но пока проект не был Open Source, мне уже приходилось разбирать его с помощью java decompiler. Декомпилированный код использовался в образовательных целях, на его основе делался плагин для hot deploy на кластер apache tomcat :) Может быть, в скором времени получится закоммитить такую возможность или выделить это как отдельную версию плагина.
Спасибо за информацию, очень интересно было усышать о нововведениях!
Насчет терминологии — правильно ли я понимаю, что под bucket подразумеваются связные списки из entry, хранящиеся в массиве конкретного сегмента?
И еще — за счет чего достигнут меньший оверхед?
Инфографика вообще здорово улучшает восприятие, согласен с вами.
Постараюсь к будущим статьям добавлять побольше иллюстраций, чтобы статьи не казались «сухими».
Однако для таких статей по параллельному доступу к структурам данных это будет оочень непросто :)
Да, именно. В приведённом мной примере я подразумевал, что мы обрабатываем множество различных сообщений, применяя к их строковому представлению метод substring(), допустим, для получения префикса.
Для одного char-массива постоянные вызовы substring() — это наоборот хорошо.
Для каждого случая — свой подход. Однако, как заметили выше, не каждый разработчик знает про эту особенность java.lang.String. Поэтому я не мог не упомянуть этот случай. Поскольку в общем виде мы приходим к тому, что «привязываемся» к некому набору данных, используя лишь его ограниченную часть.
При единичных вызовах substring() к строкам большой длины стоит, конечно же, использовать конструктор.
Спасибо за статью по оптимизационным трюкам, очень хороший материал.
По поводу поведения в обоих случаях — важные дополнения. Только не понял насчёт объектов с переопределённым finalize() — чем он помешает сборке объекта?
Вернёмся к приведённому в посте примеру с системой обработки сообщений.
Допустим, мы ведём обработку поступающих к нам сообщений, созданных по специально выбранному протоколу. Для простоты представим, что мы выполняем операцию получения префикса строк для данных сообщений и кэшируем эти значения.
Что произойдет при кэшировании десятка тысяч таких коротких префиксов при получении их через substring()? В памяти будут храниться все данные, содержащиеся во всех исходных сообщениях. И если их длина значительно превосходит суммурную длину всех префиксов в кэше, то именно на эту величину у нас и создастся утечка памяти.
Пример абстрактный, но точно отражает проблему. Мы используем нужные нам данные, заставляя перманентно храниться в памяти избыточные данные большего размера.
Имею ввиду использование потоками ThreadLocal-переменных, описанных в классах. Каждый поток будет иметь свою независимо инициализированную копию данной переменной (соответственно, и уникальную ссылку на неё), что в случае с пулами потоков и невнимательном обращении с хранимыми в ThreadLocal-данными приведёт нас к указанной проблеме.
Скажу честно, данное утверждение увидел в статье «Leaking Memory in Java» по ссылке blog.xebia.com/2007/10/04/leaking-memory-in-java
В посте говорится, что первый случай вызовет OutOfMemoryError.
Цитата про второй случай: «the second creation of the FatObject will trigger a full GC and the GC will be able to clear enough memory (since the old reference has been nulled)».
Согласен с комментарием выше о том, что время между созданиями объектов должно играть роль. Также как и момент, в который будет происходить выполнение этой операции. Конечное поведение зависит от настроек и реализации используемого GC.
Надеюсь, они не закроют теперь Google Tasks :)
Жаль, что такой возможности больше не будет. Но зато это готовая идея для чьего-то стартапа :)
Очень жду появления веб-интерфейса к этому. Такого же красивого, как айфон-версия.
А то иначе желание пополнять отпадает, не с кем поделиться красотой :)
www.youtube.com/watch?v=wM_PDC05Y4o
Да, насчёт AsyncProxy действительно странно, учитывая, что он появился уже в версии 2.0.1.
Как заявил представитель Red Hat, в их интересах обеспечить поддержку JBoss Application Platform. Более того, интереснее всего сделать плагин универсальным, дав возможность использовать его не только для одной платформы.
Тут хочется сказать Google большое спасибо.
Забавно, но пока проект не был Open Source, мне уже приходилось разбирать его с помощью java decompiler. Декомпилированный код использовался в образовательных целях, на его основе делался плагин для hot deploy на кластер apache tomcat :) Может быть, в скором времени получится закоммитить такую возможность или выделить это как отдельную версию плагина.
Насчет терминологии — правильно ли я понимаю, что под bucket подразумеваются связные списки из entry, хранящиеся в массиве конкретного сегмента?
И еще — за счет чего достигнут меньший оверхед?
Постараюсь к будущим статьям добавлять побольше иллюстраций, чтобы статьи не казались «сухими».
Однако для таких статей по параллельному доступу к структурам данных это будет оочень непросто :)
Для одного char-массива постоянные вызовы substring() — это наоборот хорошо.
Для каждого случая — свой подход. Однако, как заметили выше, не каждый разработчик знает про эту особенность java.lang.String. Поэтому я не мог не упомянуть этот случай. Поскольку в общем виде мы приходим к тому, что «привязываемся» к некому набору данных, используя лишь его ограниченную часть.
При единичных вызовах substring() к строкам большой длины стоит, конечно же, использовать конструктор.
По поводу поведения в обоих случаях — важные дополнения. Только не понял насчёт объектов с переопределённым finalize() — чем он помешает сборке объекта?
Допустим, мы ведём обработку поступающих к нам сообщений, созданных по специально выбранному протоколу. Для простоты представим, что мы выполняем операцию получения префикса строк для данных сообщений и кэшируем эти значения.
Что произойдет при кэшировании десятка тысяч таких коротких префиксов при получении их через substring()? В памяти будут храниться все данные, содержащиеся во всех исходных сообщениях. И если их длина значительно превосходит суммурную длину всех префиксов в кэше, то именно на эту величину у нас и создастся утечка памяти.
Пример абстрактный, но точно отражает проблему. Мы используем нужные нам данные, заставляя перманентно храниться в памяти избыточные данные большего размера.
В посте говорится, что первый случай вызовет OutOfMemoryError.
Цитата про второй случай: «the second creation of the FatObject will trigger a full GC and the GC will be able to clear enough memory (since the old reference has been nulled)».
Согласен с комментарием выше о том, что время между созданиями объектов должно играть роль. Также как и момент, в который будет происходить выполнение этой операции. Конечное поведение зависит от настроек и реализации используемого GC.