В продолжение темы C++ vs ???

Автор: zip_
Дата: 30.11.05

Постулат №1:
GC это хорошо и malloc/free тоже хорошо.

В поисках идеала (для UI programing) пришел к следующему выводу:
GC как средство макроменеджмента памяти это то что нужно.
GC как средство микроменеджмента памяти это дрова.
Микроменеджмент памяти это прерогатива malloc/free и stack allocation.

Что есть macro и micro management? Поясню на примере:

Классический () подход современных Java или WinForms.net:

Скажем для того чтобы залить прямоугольгик каким-нибудь цветом мы имеем:

class Brush { Color color; ... }

class Graphics 
{  
  void fillRect( Rect r );
}

Brush b = new Brush( new Color(0xFF,0,0) ); 
Rect r = new Rect( 10,10,100, 100 );

gfx.setBrush(b);
gfx.fillRect(r);

В данном случае Java выполняет менджмент микро объектов Rect и Brush — создает и удаляет их. Как следствие система жутко не эффективная. Как правило Brush это обертка над системным HBRUSH в конце концов. Т.е. к тому же имеем еще и dispose со всеми вытекающими.
Brush как отдельный объект никому не нужен. Как правило все что с ним делается это вызывается конструктор и все.
Rectangle в общем-то тоже как самостоятельный объект представляет мало ценности. Тогда зачем они? (см. далее про j-smile)

Постулат №2:

Если некая GC система (runtime например) требует интенсивного explicit dispose это
означает ошибку в дизайне этой самой системы/runtime.
Код требующий dispose нужно выносить на уровень микроменеджмента.

Что я попытался сделать в j-smile (микро/макро был одной из основных идей дизайна):
тот же фрагмент кода выглядит так:

// class Brush { Color color; ... } - просто нет этого как сущности
// Color тоже нет. Вернее есть, но не как объект, а namespace для стат. функций. 

class Graphics 
{  
  void fillRect( int x, int y, int w, int h );
}

gfx.setBrush(Color.RGB(0xFF,0,0));
gfx.fillRect(10,10,100, 100);

Менеджмент HBRUSH и всего такого (микроменеджмент) выполняет
С имплементация класса Graphics. Заведомо максимально эффективным образом.
Java же управляет макро объектами Windget, Widgets (container) и т.д.

Все вместе а) значительно снижает нагрузку на GC (мало объектов — мало мусора)
b) значительно снижает требования к самой VM Java — все интенсивные
вычисления делаются на стороне C.
Если посомтреть то j-smile-demo.exe
(самописная VM + copying GC) тактильно работает в общем-то c той же скоростью что
и Harmonia примеры ( D c крутым codegen ). И объем exe в общем-то идентичен.
j-smile-demo.exe это двоичный bundle: 200k(VM+runtime) + 200k bytecodes (noncompressed .class files)
Откомпилированные D самплы по размеру бинарников соизмеримы.


Постулат №3
Оптимальная система оптимально использует разные
механизмы memory managment.
"Все — managed" это имхо грубейшая ошибка дизайна которая например убила Java UI на корню.
.NET UI (WinForms) слепо содрав подход AWT/SWT успешно двигается в
том же самом направлении.

Вот такие вот мои мысли в слух если они кому интересны.