Sun расширяет спектр Linux ПО

http://www.apple.com/java/

Less memory, faster start

On other platforms, each Java application consumes some system memory. So you might end up using more memory than you need to when running multiple Java applications. Other languages, such as C or C++, solve this problem using what’s called shared libraries. Apple developed an innovative new technology that allows Java code to be shared across multiple applications. This reduces the amount of memory that Java applications normally use. And it fits right into Sun’s Hot Spot VM, allowing Mac OS X to remain compatible with standard Java. In addition, Apple has given this implementation to Sun so the company can deploy it on other platforms. Just one example of how Apple supports standards and shares ideas to benefit all.

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

>> память под структуры выдяляется прямо из стека без обращения к GC.

> Прямо из стека? То есть, если я в методе создал структуру, после выхода из метода я ее уже не увижу?

Если структуру возвращать как результат метода, то, судя по всему, она копируется через тот же стек. А в чем собственно, проблема? Этот механизм работает на тех же самых принципах, что и передача объектов и структур по значению в C/C++.

Исключение составляет автоматический boxing, если возвращаемый тип - интерфейс, а уже не структура (которые могут реализовывать интерфейсы). В таком случае задействуется GC.

Так что, данные сохраняются с любом случае.

Структура позволяет сильно оптимизировать работу с итераторами (в .NET это IEnumerator), а также с такими маленькими объектами как точка (System.Drawing.Point), прямоугольник (System.Drawing.Rectangle) и т.п.

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

Вот именно такой возможности IMHO очень сильно и не хватает яве, а жаль...

>> Прямо из стека? То есть, если я в методе создал структуру, после выхода из метода я ее уже не увижу?

> Если структуру возвращать как результат метода, то, судя по всему, она копируется через тот же стек.

А если я в метод передал ссылку на структуру, инициализированную null (я в терминах Java), а в методе ей присвоил значение ссылки на свежесозданную структуру? Тоже копирование по значению будет?

> А в чем собственно, проблема? Этот механизм работает на тех же самых принципах, что и передача объектов и структур по значению в C/C++.

В C++ если создать auto_ptr в функции и попытаться его вернуть через переданную в функцию ссылку же на auto_ptr, после возврата из функции вернется мусор. Мне вот интересно, как это в .NET обошли. Запретили вообще или в таких случаях включают умный механизм?

> Дожили, блин.

Если Вы умный анонимус, ответьте на мой вопрос ниже, если глупый - подите прочь!

> Для тех, кто не знает, память под структуры выдяляется прямо из стека без обращения к GC.

Классно!!! GC теперь ещё и память выделяет? А я до сих пор думал, что он её освобождает.

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

>А если я в метод передал ссылку на структуру, инициализированную null (я в терминах Java), а в методе ей присвоил значение ссылки на свежесозданную структуру?
Это снова я, твой любимый тупой анонимус. Напиши мне плиз на С# присвоение указателю ссылки на структуру.

> Это снова я, твой любимый тупой анонимус. Напиши мне плиз на С# присвоение указателю ссылки на структуру.

Читать умеете, нет? Где у меня слово "указатель" в тексте. C# не изучал еще, напишу на Java.

CSharpStructure structure = null; ... CSharpStructure structure2 = new CSharpStructure(); structure = structure2;

> Классно!!! GC теперь ещё и память выделяет? А я до сих пор думал, что он её освобождает.
Прикинь, да? О сколько нам открытий чудных...
> А, если серьёзно, иди читай hotspot whitepaper, где hotspot jvm выделяет память для короткоживущих объектов.
Десять раз уже читали. Где? Почитай, а еще подумай как априори определить время жизни объета.

> structure = structure2;

Послушай, ты чего действительно так непробиваем? Или ява нафик отшибла value types?

> Или ява нафик отшибла value types?

При чем тут ява? Я и другие языки знаю вообще-то. Я, вроде бы, уже объяснял - C# я не знаю, а ты вместо того, чтобы объяснить что там к чему, пальцы гнешь. Совесть есть?

Вопрос снят, кстати. Разобрался уже.

Ну извини, погорячился.

Да ладно, с кем не бывает.

Ну чего, питекантроп, прочитал? или тебе перевести?

2pitekantrop: Классно!!! GC теперь ещё и память выделяет? А я до сих пор думал, что он её освобождает. А, если серьёзно, иди читай hotspot whitepaper, где hotspot jvm выделяет память для короткоживущих объектов.

Эх, темнота... Электронная книга "Java Platform Performance" от одних из авторов Свинга Steve Wilson и Jeff Kesselman, глава "Appendix A. The Truth About Garbage Collection":

"...

Garbage collection (GC) is probably the most widely misunderstood feature of the Java platform. GC is typically advertised as removing all memory management responsibility from the application developer. This just isn't the case.

...

The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector);

... "

Другими словами GC - это "система автоматического управления памятью" (automatic storage management system), а "сборщик мусора" (garbage collector) лишь одна из ее обязаностей. Вот так-то, студент.

2 anonymous (*) (22.01.2004 18:05:43)
Ладно, фик с ним, похоже он управляемую кучу со стеком перепутал. Гораздо интереснее где у нас в Яве теперь большие объекты хранятся?

> Десять раз уже читали. Где? Почитай, а еще подумай как априори определить время жизни объета.

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

> Тебе это время знать очень нужно? Они живут, пока nursery не переполнится.
Мне нет, надо тебе если ты их собрался в стек пихать. А nursery он где? Правильно, в куче, которая хоть и managed, но стек не догонит по определению. ЧТД.

> Ладно, фик с ним, похоже он управляемую кучу со стеком перепутал.

Я кучу со стеком не путал. Похоже, что сборкой мусора в яве теперь называют всё управление памятью, а не только собственно процедуру поиска "мёртвых душ". Ну да ладно, как говорится, назовись хоть лебедем... ^))

> Мне нет, надо тебе если ты их собрался в стек пихать.

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

> А nursery он где? Правильно, в куче, которая хоть и managed, но стек не догонит по определению. ЧТД.

Ну, С++ heap его (nursery) тоже не догонит.

Ну ладо, не путал, так не путал. Ты нам про generation garbage collector рассказывал, который в дотнете с рождения. Причем тут структуры тогда? И что за мода такая пошла все сводить к выделению памяти, это что все чем new занимается? И про эти, как их, большие объекты расскажи что вычитал...

> Ну, С++ heap его (nursery) тоже не догонит
Догонит и перегонит, только не сразу :)

Кстати, кто-нибудь знает, как санка живет на десктопе. Или никто не видел такого изврашения?

> Ты нам про generation garbage collector рассказывал, который в дотнете с рождения.

Мне аж интересно стало, кто автор? Вроде, самая старая статья, которую я нашёл - Simple Generational Garbage Collection and Fast Allocation (1988) Andrew W. Appel

> Причем тут структуры тогда?

Что касается выделения памяти в стеке - так я за, если оно быстрее. Однако я считаю, что компилятор должен определять время жизни объекта и принимать решение о размещении объекта в стеке, а не программист. А вообще, проблемы производительности в J2SE 1.4.2, ИМХО, уже почти не существует. Она есть только как следствие большого апетита на память: свопление на диск - ну уж очень небыстрая операция. А в J2EE на 1 место выходит правильно организованное кэширование, использование только Stateless Session Beans и прочие зависимости от радиуса рук и количества извилин у прикладных разработчиков.

> И что за мода такая пошла все сводить к выделению памяти, это что все чем new занимается?

Здесь я дествительно не знаю, чем ещё new занимается. Инициализацией полей нулями? Хотя, скорее всего, всё nursery за один раз обнуляется. Вообщем, просвети дремучего :)

> И про эти, как их, большие объекты расскажи что вычитал...

Я говорил только про короткоживущие. А что, для больших есть отличия?

>Покажи мне на OCaml фреймворк который сравним по функционалу со свингом?

Фи. Сделать биндинги к любой из существующих библиотека -- это 2-3 человеконедели.

>покажешь как она поместиться в 30 метров = тогда и будешь этих сказок расказывать.

А какие именно сказки? Про память я вроде ничего не говорил. Жаба меня дастало вечным глюкодромом и обилием дебилов за 21 день деланных. Окамл эту "мразь"(с)Луговский в состоянии отфильтровать.

Что-то особую прожерливость OCaml в плане памяти не замечал, разве не программер определяет, какие структуры данных используются и что загружается в память, а что нет? Про Unicode вообще как-то не в тему, что вообще мешает с ним работать, или отсутствие готовой либы, сразу ставит в тупик? Привязки к C есть, если необходимо что-то внешнее подцепить. Да и изучить при желание можно за пару недель, при этом не будет никаких сюрпризов с синтаксисом, в виде магических переменных или ещё чего. Поначалу система типов будет напрягать, и говорить, что вы лох, но через пару месяцев все образуется. Что касается работы, то на OCaml я в основном работаю с DB, XML/HTML Parsing, Networking, каких-либо проблем или глюков не было как класса. В общем отличная альтернатива C,С++,Java,Perl и Python.

> Жаба меня дастало вечным глюкодромом и обилием дебилов за 21 день деланных.

Это наверное ты её достал глюкоделанием, потому что за 21 делался.

>>Покажи мне на OCaml фреймворк который сравним по функционалу со свингом? > Фи. Сделать биндинги к любой из существующих библиотека -- это 2-3 человеконедели.

Тогда тренируйся. Када мне надо будет я себе операционку напишу меня устраивающую - да жаль времени все нет - с чего бы это? Потенциальные возможности сделать что либо вообще и в принципе меня, как человека занятого в производстве, а не в исследовательских изысканиях слабо интересуют. Если мне хватает хаскела - пишу на хаскеле. Если не хватает - я не не сижу и пузырей не пускаю и не молюсь, что это в принципе возможно.

> А какие именно сказки? Про память я вроде ничего не говорил. Жаба меня > дастало вечным глюкодромом и обилием дебилов за 21 день деланных. Окамл > эту "мразь"(с)Луговский в состоянии отфильтровать.

О - тебя очень беспокоин наличие в мире людей не знающих Хиндлея и Мильнера и не поклоняющихся Полу Грему? И ты поставил великую цель заниматься фильтрацией людей с целью поставки материала для известного биореактора? Тогда да - тогда у тебя проблема. Я бы сказал психического плана.

> Что-то особую прожерливость OCaml в плане памяти не замечал, разве не программер определяет, какие структуры данных используются и что загружается в память, а что нет?

Тривиальный пример:

# let l = [2;3;4;5];; # let l = 1 :: l;;

Скока займется памяти?

> Про Unicode вообще как-то не в тему, что вообще мешает с ним работать, или отсутствие готовой либы, сразу ставит в тупик?

Вообще-то, отсутствие готовой либы меня обычно огорчает.

Касательно unicode:

LablGtk предполагает, что сторки в UTF-8, что хорошо. Но все ли готовые либы работают со строками в UTF-8? Если бы строки в OCaml всегда хранились в UTF-8, проблем было бы меньше.

Для 32-битной системы: 72 байта (+) несколько байт под длину и тип данных, если считать по 4 байта под число и ещё 4 под ссылку на следующий элемент, хотя ссылка может быть меньше 4 байт, я реализацию не копал, думаю возможно и динамически менять в зависимости от размера списка и расположения в памяти. Ну и через какое-то время GC освободит 32 байта, останется 40.

В общем список есть список...на таблицу в памяти явно не похож.

В этом же примере можно было написать и так: let a = [|2;3;4;5|];; let a = Array.concat [[|1|];a];;

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

UTF-8 - это однобайтовая кодировка, ку-ку. Обычные OCaml строки прекрасно могут хранить UTF-8. И какие такие готовые либы, которые должны работать с UTF-8?

Можно посмотреть ocamlnet->netstring->netconversion ... всего 1000 строк кода на все про все, разобраться не сложно.

> Итак понятно, что есть небольшие издержки, зато реально круто.

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

> UTF-8 - это однобайтовая кодировка, ку-ку. Обычные OCaml строки прекрасно могут хранить UTF-8. И какие такие готовые либы, которые должны работать с UTF-8?

Хранить могут прекрасно. А вот даже подсчёт количества символов уже отличается. А что, нет либ, которые делают что-нибуть сложное со строками? Попробуй написаить функцию, которая переставляет символы в обычной строке в обратном порядке и натравить её на UTF-8.

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

А что касается накладных расходов в OCaml - они явно невелики, если с С сравнивать. И проектов, где это бы стало узким местом, не так много. К тому же если вспомнить C/C++, то там каждый сам следит за памятью и проверкой границ, а если ещё поюзать STL, то получиться еще менее эффективно, чем в OCaml.

Так что вполне возможно его рассматривать как промышленный язык, каком он собственно и является.

В общем рефакторинг и прочие модификации программ на порядок легче и надежнее выполняются.

>Попробуй написаить функцию, которая переставляет символы в обычной строке в обратном порядке и натравить её на UTF-8.

Я такие фокусы делать не буду - ибо лишено смысла это делать без учета управляющих символов.

И надо полагать работать в таком случае надо, не с UTF-8, а с 2-х байтовой Unicode.

UTF-8 - скорее транспортная кодировка, и не предназначена для сложных манипуляций со строками. Создавалась спецально, чтобы работать с Unicode без внесения изменений в системные либы.

>> Tiger (1.5) pozvolit ispol'zovat' tol'ko 1 mashinu dlya raznyh prog

> Этого в 1.5, скорее всего, не будет: http://developer.java.sun.com/developer/bugParade/bugs/4416624.html

Пофиксили!!! Будет в 1.5!

> И надо полагать работать в таком случае надо, не с UTF-8, а с 2-х байтовой Unicode.

Если надо, чтобы символы занимали одинаковое место, надо работать с 4хбайтовой кодировкой. Unicode уже перерос 2 байта.

Неплохо навтыкали :) Ну четрые так четыре, это наверное все-таки проще в реализации будет, просто сделать символ в строке не 8-битным, а 32-битным, пару функций Char4.code, Char4.chr и модуль String4, остальное все как обычно. Наверное имеет смысл сделать поддержку на уровне основного типа данных, за 4-е байта уж точно не вылезут, 4 млрд. как никак.

> за 4-е байта уж точно не вылезут, 4 млрд. как никак

Создатели tcp/ip тоже так думали :)