Здравствуйте, Cyberax, Вы писали:

C>Вообще-то, внутри JDK алгоритмы GC находятся в раздельных модулях и
C>вполне себе автономны.

Это не важно. Главное, что они в рамках одного продукта и меняются путем задания настроек (без переинсталляции).

Вот же, сила воли у тебя: не хотел со мной общаться, общаешся.

VladD2 wrote:
> C>А вот Ротор — он действительно ничем не поможет, там примитивный GC.
> Я бы сказал упрощенный. И как раз понять как работает ЖЦ очень даже
> помогает, так как инфраструктура там та же самая.
Там нет очень многих интереснейших и важных моментов. Например,
организации точек останова и сопутствующих registry- и stackmap'ов. Еще
там очень примитивная организация поколений, нет компактификации кучи и т.п.

> Хотя конечно не помешало бы имать исходники алгоритмов применяемых в
> дотнете. Но видимо это коммерческая тайна.
А что еще от MS ожидать? Они бы хоть стандартную библиотеку выпустили в
исходниках.

Здравствуйте, AndrewVK, Вы писали:


V>>Сетевой протокол CORBA очень продуман, и легко расширяем, в отличие от ремотинга донета.

AVK>У ремоутинга нет сетевого протокола.

Там в качестве протокола выступает выбранный протокол сериализации сообщений.


V>> Я имею ввиду, что если будет желание, например, как-то расширить стандартный ремотинг путем своих каналов или там еще чего (для передачи, скажем, неких атррибутов, привязанных к конкретным вызовам методов удаленных объектов), то это вступит в конфликт с другими компонентами системы

AVK>Например?

Пакет сообщения CORBA немного самоописываем, т.е. в определенном месте можно вставлять некие "свои" данные. Приемная сторона, т.е. некая CORBA-либа разбирает все, что может разобрать, как минимум разбирает пакет согласно номеру стандарта (сначала выбирают наибольший поддерживаемый номер стандарта, на котором осуществляется общение), и если позволяет реализация, то можно добавлять свои данные, которые не мешают остальным. Данные могут быть какие угодно, например, хинты блокировок или там закодированные "пожелания" по реакции на исключения и т.д. Разумеется, вручную управлять этими данными неудобно, но если речь идет о какой-нить автоматизированной системе, то весьма удобно. Как аналогию можно привести кастомные аттрибуты из донета (которые могут быть исопльзованы "очень много зачем"), но здесь подразумевается возможность их динамической передачи во время на вызова удаленного метода.

Cyberax wrote:
>> C>А вот Ротор — он действительно ничем не поможет, там примитивный GC.
>> Я бы сказал упрощенный. И как раз понять как работает ЖЦ очень даже
>> помогает, так как инфраструктура там та же самая.
> Там нет очень многих интереснейших и важных моментов. Например,
> организации точек останова и сопутствующих registry- и stackmap'ов. Еще
> там очень примитивная организация поколений, нет компактификации кучи и т.п.
Дополню, чтобы мне не тыкали потом на ошибки. В Rotor'е точки останова
(GC safepoints) выставляются только в начале и конце методов, так что
такой вот код вызовет "пятисекундную паузу":

//Thread 1
void theEternalLoop()
{
   while(true){};
}

//Thread 2
void doSomething()
{
   SomeObj obj=new SomeObj(); //Здесь случается GC...
   //...но сюда мы никогда не попадем.
}

Здравствуйте, Cyberax, Вы писали:

C>VladD2 wrote:
>> C>А вот Ротор — он действительно ничем не поможет, там примитивный GC.
>> Я бы сказал упрощенный. И как раз понять как работает ЖЦ очень даже
>> помогает, так как инфраструктура там та же самая.
C>Там нет очень многих интереснейших и важных моментов. Например,
C>организации точек останова и сопутствующих registry- и stackmap'ов.

Это все там есть.

C> Еще там очень примитивная организация поколений, нет компактификации кучи и т.п.

Это да сам алгоритм там урощенный.

C>А что еще от MS ожидать? Они бы хоть стандартную библиотеку выпустили в
C>исходниках.

В роторе BCL идет.

Здравствуйте, vdimas, Вы писали:

AVK>>У ремоутинга нет сетевого протокола.

V>Там в качестве протокола выступает выбранный протокол сериализации сообщений.

Вот именно. И подсунуть можно хоть IIOP. Было бы желание.

V>>> Я имею ввиду, что если будет желание, например, как-то расширить стандартный ремотинг путем своих каналов или там еще чего (для передачи, скажем, неких атррибутов, привязанных к конкретным вызовам методов удаленных объектов), то это вступит в конфликт с другими компонентами системы

AVK>>Например?

V>Пакет сообщения CORBA немного самоописываем, т.е. в определенном месте можно вставлять некие "свои" данные. Приемная сторона, т.е. некая CORBA-либа разбирает все, что может разобрать, как минимум разбирает пакет согласно номеру стандарта (сначала выбирают наибольший поддерживаемый номер стандарта, на котором осуществляется общение), и если позволяет реализация, то можно добавлять свои данные, которые не мешают остальным. Данные могут быть какие угодно, например, хинты блокировок или там закодированные "пожелания" по реакции на исключения и т.д. Разумеется, вручную управлять этими данными неудобно, но если речь идет о какой-нить автоматизированной системе, то весьма удобно. Как аналогию можно привести кастомные аттрибуты из донета (которые могут быть исопльзованы "очень много зачем"), но здесь подразумевается возможность их динамической передачи во время на вызова удаленного метода.

Я тебя про проблемы ремоутинга спрашивал, а ты мне про CORBA рассказываешь.

Здравствуйте, AndrewVK, Вы писали:


AVK>Вот именно. И подсунуть можно хоть IIOP. Было бы желание.

Сериализация произвольных дотнетных структур данных не ложится на IIOP, к сожалению. Особенно это относится к абстрактным типам, передаваемым по-значению, к Object в первую очередь, разумеется.

Здравствуйте, vdimas, Вы писали:

V>Сериализация произвольных дотнетных структур данных не ложится на IIOP, к сожалению.

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

VladD2 wrote:
> ANS>Что задержки именно от сборки мусора, а не от того, тчо программа
> такая это ты инфу из астрала получил?
>
> Это совершенно очевидно. Тормоза случаются переодически при скролинге.
> Если бы проблема была алгоритмической, то тормоза были бы постоянно. А
> так они происходят через определенный промежуток времени. Ели тебе
> интересно, можешь поглядеть чем-нибудь информацию о сборках.

Сразу резко вспомнилось, что xpdf (написанный на unsafe языке без GC)
имеет именно из-за алгоритмически не очень удачного кеширования
отрисованной области за краями экрана именно "тормоза периодически при
скроллинге, а не постоянно". При том, что и в xpdf и в JEdit тормозит,
вероятно, отрисовка...

Здравствуйте, AndrewVK, Вы писали:

V>>Сериализация произвольных дотнетных структур данных не ложится на IIOP, к сожалению.

AVK>Ложится, если с умом подойти. EJB ложится, а в ремоутинге от него никаких принципиальных отличий нет.

С умом, в смысле — учесть все ограничения? Это да, согласен. Для прогона RMI через GIOP (IIOP — это GIOP по интернету) изначально введены ограничения, которые позволяют отображать RMI на GIOP:

1.2 The RMI/IDL Subset of Java
This section describes the subset of Java RMI that is mapped to IDL and can run over
GIOP.
1.2.1 Overview of Conforming RMI/IDL Types
A conforming RMI/IDL type is a Java type whose values may be transmitted across an
RMI/IDL remote interface at run-time.
A Java data type is a conforming RMI/IDL type if it is:
• one of the Java primitive types (see Section 1.2.2, “Primitive Types,” on page 1-2).
• a conforming remote interface (as defined in Section 1.2.3, “RMI/IDL Remote
Interfaces,” on page 1-3).
• a conforming value type (as defined in Section 1.2.4, “RMI/IDL Value Types,” on
page 1-4).
• an array of conforming RMI/IDL types (see Section 1.2.5, “RMI/IDL Arrays,” on
page 1-5).
• a conforming exception type (see Section 1.2.6, “RMI/IDL Exception Types,” on
page 1-5).
• a conforming CORBA object reference type (see Section 1.2.7, “CORBA Object
Reference Types,” on page 1-6).
• a conforming IDL entity type (see Section 1.2.8, “IDL Entity Types,” on page 1-6).
1.2.2 Primitive Types
All the standard Java primitive types are supported as part of RMI/IDL. These are:
• void, boolean, byte, char, short, int, long, float, double
September 2003 Java to IDL Mapping: The RMI/IDL Subset of Java 1-3
1
1.2.3 RMI/IDL Remote Interfaces
An RMI remote interface defines a Java interface that can be invoked remotely. A Java
interface is a conforming RMI/IDL remote interface if:
1. The interface is or inherits from java.rmi.Remote either directly or indirectly.
2. All methods in the interface are defined to throw
java.rmi.RemoteException or a superclass of
java.rmi.RemoteException. Throughout this section, references to methods
in the interface include methods in any inherited interfaces.
3. There are no restrictions on method arguments and result types. However at runtime,
the actual values passed as arguments or returned as results must be
conforming RMI/IDL types (see Section 1.2.1, “Overview of Conforming RMI/IDL
Types,” on page 1-2). In addition, for each RMI/IDL remote interface reference, the
actual value passed or returned must be either a stub object or a remote interface
implementation object (see Section 1.2.3.1, “Stubs and remote implementation
classes,” on page 1-4).

...

1.2.4 RMI/IDL Value Types
An RMI/IDL value type represents a class whose values can be moved between
systems. So rather than transmitting a reference between systems, the actual state of
the object is transmitted between systems. This requires that the receiving system have
an analogous class that can be used to hold the received value.
Value types may be passed as arguments or results of remote methods, or as fields
within other objects that are passed remotely.
A Java class is a conforming RMI/IDL value type if the following applies:
1. The class must implement the java.io.Serializable interface, either directly
or indirectly, and must be serializable at run-time. It may serialize references to
other RMI/IDL types, including value types and remote interfaces.
2. The class may implement java.io.Externalizable. (This indicates it
overrides some of the standard serialization machinery.)
3. If the class is a non-static inner class, then its containing class must also be a
conforming RMI/IDL value type.
4. A value type must not either directly or indirectly implement the
java.rmi.Remote interface. (If this were allowed, then there would be potential
confusion between value types and remote interface references.)

September 2003 Java to IDL Mapping: The RMI/IDL Subset of Java 1-5
1
5. A value type may implement any interface except for java.rmi.Remote.
6. There are no restrictions on the method signatures for a value type.
7. There are no restrictions on static fields for a value type.
8. There are no restrictions on transient fields for a value type.
9. Method, constant, and field names must not cause name collisions when mapped to
IDL (see Section 1.3.2.10, “Names that would cause OMG IDL name collisions,”
on page 1-10).

...

1.2.7 CORBA Object Reference Types
A conforming CORBA object reference type is either
• the Java interface org.omg.CORBA.Object, or
• a Java interface that extends org.omg.CORBA.Object directly or indirectly and
conforms to the rules specified in the Java Language Mapping (i.e., could have been
generated by applying the mapping to an OMG IDL definition).

Выделил интересную часть. Создаются трудности для передачи абстрактных типов по значению. Причина понятна, CORBA должна обеспечивать передачу типов по значению в гетерогенной среде, где может не оказаться подходящей иерархии абстрактных классов, более того, может не оказаться самой возможности наследования классов в некоей конкретной среде.

В этом стремлении к поддержке гетерогенных сред и сила и слабость OMG. Уверен, что к 4-му или 5-му стандарту во главу угла будет поставлены цель интероперабельности Java и .Net, тогда придется снова ввести многое из того, что делать было нельзя из-за гетерогенной направленности. Ведь на C++ по-любому что угодно отбразить можно, а возможности ObjectPascal близки к возможностям Java, которые достаточны для ремоутинга. Если отказаться от коболов и прочей экзотики, оставив Object Pascal, C++, Java, .Net, то вполне можно разработать современный и удобный стандарт на интероперабельность (пока что стандарт очень ограничен в специфицированной части, ИМХО из-за этого открыт для расширения в бинарном протоколе, дабы иметь возможность для обхода "особых случаев").

Здравствуйте, raskin, Вы писали:

R> При том, что и в xpdf и в JEdit тормозит,
R>вероятно, отрисовка...

Отрисовка там не тормозит. Там случаются приодические задержки в сдествии активизации ЖЦ и плохого алогоритма инкрементальной сборки. Это признают все с кем я это в свое время обсуждал. Да и есть разные профйлеры. Собственно выявилось это когда я услышал совершенно дурацкий на мой взгляд совет по отимизации работы со строками. Для дотнета он был совершенно бессмысленным. Меж тем на Яве он говоря помогает.

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

Здравствуйте, VladD2, Вы писали:

VD>Отрисовка там не тормозит. Там случаются приодические задержки в сдествии активизации ЖЦ и плохого алогоритма инкрементальной сборки. Это признают все с кем я это в свое время обсуждал. Да и есть разные профйлеры.

Профайлеры тут нафиг не упали. Есть опция командной строки, которая выводит время работы GC. Это объективный показатель. А на глаз определять тормоза GC — дурость неимоверная.

VD>Собственно выявилось это когда я услышал совершенно дурацкий на мой взгляд совет по отимизации работы со строками. Для дотнета он был совершенно бессмысленным. Меж тем на Яве он говоря помогает.


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

Здравствуйте, vdimas, Вы писали:

V>В этом стремлении к поддержке гетерогенных сред и сила и слабость OMG. Уверен, что к 4-му или 5-му стандарту во главу угла будет поставлены цель интероперабельности Java и .Net, тогда придется снова ввести многое из того, что делать было нельзя из-за гетерогенной направленности.

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

Здравствуйте, WolfHound, Вы писали:

AVC>>Думается, для того же, для чего нужны безопасные языки и сборка мусора, — для надежности.
AVC>>Активные объекты — развитие мониторов Хансена и Хоара, а мониторы всяко надежнее бессистемного управления потоками.
AVC>>В каком-то смысле — это та же инкапсуляция (данных, потоков и блокировок).
WH>А теперь попробуй объяснить чем синхронизация на активнах объектах лучше чем синхронизации на каналах?

Очень поверхностно ознакомился с идеями Сигулярити — прочел (пока) один обзор.
Во-первых, мне Сигулярити нравится.
Уже хотя бы из-за SIP аббревиатуры (Software Isolated Process).
Ты уж извини, но здесь я опять-таки вижу аналогию с Обероном (если взять слово Software).
Насколько я понял, основное различие в том, что Сингулярити (программно) поддерживает несколько процессов.
В принципе, это должно быть хорошо.
В первоначальном Обероне был только один поток, в Aos (BlueBottle) — многопоточность, а вот процессов в их традиционном для ОС понимании не было.
Вполне возможно, что это шаг вперед (и серьезный).
Вместе с тем, разделение (пусть и программное) процессов все-таки накладывает некоторые ограничения.
Например, процессы не могут обмениваться между собой объектами.
Что, ИМХО, можно считать ограничением, т.к. современные программные системы во многом строятся из объектов.

Здравствуйте, WolfHound, Вы писали:

WH>А теперь попробуй объяснить чем синхронизация на активнах объектах лучше чем синхронизации на каналах?

Синхронизация на каналах — это частный случай синхронизации на объектах.
Синхронизация на объектах — более общий, а стало быть, более мощный способ.

Активные объекты, как и положено объектам, могут вызывать методы друг друга. Вызов метода — это обычный процедурный вызов. Это очень быстро, у процессоров для этого есть специальные инструкции. SIP так не умеют.

Здравствуйте, absolute, Вы писали:

A>Синхронизация на каналах — это частный случай синхронизации на объектах.
A>Синхронизация на объектах — более общий, а стало быть, более мощный способ.
Правда? А вот я всегда думал что на оборот...
В случае каналов я могу на произвольное колличество произвольных запросов получить произвольное колличество произвольных ответов. А в случае с объектами я могу на один конкретный запрос получить только один конкретный ответ.
Также не забываем про асинхронность сообщений... те я могу послать сообщение и занятся полезной работой, а не висеть в синхронном вызове куря бамбук. Особенно это хорошо если нужно послать сообщения по нескольким каналам и потом ждать от них ответа.
В случае с синхронными запросами все запросы будут отрабатываться последовательно, а в моем случае паралельно.
Так что тут частный случай?
Кстати как там с установкой таймаута при вызове активного объекта?

A>Активные объекты, как и положено объектам, могут вызывать методы друг друга. Вызов метода — это обычный процедурный вызов. Это очень быстро, у процессоров для этого есть специальные инструкции. SIP так не умеют.
Только ты забыл про то что это не только обычный вызов но еще и захват монитора. А во что это выльется хотябы на кластере я вобще подумать боюсь... кури DCOM и CORBA и то и другое работает весьма хреново ибо RPC, а RPC это ошибка природы и должен умереть. Вся эта "прозрачность" на практике не только ничего не дает но и мешает нормальной декомпозиции ситемы.

Здравствуйте, AVC, Вы писали:

AVC>Очень поверхностно ознакомился с идеями Сигулярити — прочел (пока) один обзор.
AVC>Во-первых, мне Сигулярити нравится.
AVC>Уже хотя бы из-за SIP аббревиатуры (Software Isolated Process).
AVC>Ты уж извини, но здесь я опять-таки вижу аналогию с Обероном (если взять слово Software).
На этом сходство с обероном заканчивается.
А идея программной изоляции просто витает в воздухе...

AVC>Насколько я понял, основное различие в том, что Сингулярити (программно) поддерживает несколько процессов.
AVC>В принципе, это должно быть хорошо.
AVC>В первоначальном Обероне был только один поток, в Aos (BlueBottle) — многопоточность, а вот процессов в их традиционном для ОС понимании не было.
AVC>Вполне возможно, что это шаг вперед (и серьезный).
AVC>Вместе с тем, разделение (пусть и программное) процессов все-таки накладывает некоторые ограничения.
AVC>Например, процессы не могут обмениваться между собой объектами.
Могут по значению.

AVC>Что, ИМХО, можно считать ограничением, т.к. современные программные системы во многом строятся из объектов.
Вот только в современных системах общение все сильнее смещается к DTO предаваемым по значению. Ибо предача объекта по ссылке в другой процесс я уже молчу про другую машину продемонстрировала свою ущербность.
Оно конечно работает но работает весьма хреново.

Здравствуйте, WolfHound, Вы писали:

AVC>>Вместе с тем, разделение (пусть и программное) процессов все-таки накладывает некоторые ограничения.
AVC>>Например, процессы не могут обмениваться между собой объектами.
WH>Могут по значению.

С методами?

Здравствуйте, AVC, Вы писали:

AVC>>>Например, процессы не могут обмениваться между собой объектами.
WH>>Могут по значению.
AVC>С методами?
Зачем? Сейчас все больше народ склоняется к передачи просто структуированных данных без поведения.
Передача объектов с поведением это вобще весьма проблемная задача с кучей подводных камней из серии где выполнять методы, какие у этих методов права и тп...