Mozilla (rc1) i java

[Tomasz Kłoczko]

On Sun, 21 Apr 2002, wrobell wrote:

> On Sun, Apr 21, 2002 at 09:33:50PM +0200, Tomasz Kłoczko wrote:
> > On Sun, 21 Apr 2002, wrobell wrote:
> > [..]
> > > Tak więc zdanie "jedna ma włączone wsparcie do LDAP, a druga nie"
> > > nie jest, o ile mi wiadomo dzisiaj, prawdziwe.
> > 
> > To było o tym co różni dwa spece dla tych pakietów.

> Gołym okiem  jest to  jedyna różnica. Jak  napisałem, diabeł
> tkwi w szczegółach. Takie  same pliki różnią się zawartością
> pomiędzy normalną  wersją i wersją embedded,  co powodowało,
> że wersja embedded  działała gorzej. Tak było  w każdym bądź
> razie dla wersji sprzed 0.9.8.

A wiesz może jak to teraz wygląda ?
Jak znajdziesz czas o ile nie wiesz to prośba .. sprawdź (wiesz już
co sprawdzać więc będzie Ci łatwiej niż komuś innemu :)

I jeszcze jedno pytanie które mi się ciśnie. Otóż jak się popatrzy na
wynik pmapa z galeona to wpadaja tam komponenty które de facto nie są
użwyane w tej aplikacji. Dotyczy to np. libeditor.so (galeon nie wspiera
edycji dokumenytów a powyższe można przypuszczać że ma związek z edycją
.. ?). Ciekawe czy gdyby w wydzielonym z pakiecie potrzebnym do
działnia galeonowi nie było tego modułu czy kilku innych komponentów to
czy galeon by zadziałał ?
Zja zadziała mozilla o ile tego modułu nie bedzie ? Będzie widoczna 
pozycja w menu czy nie ? Jęzlei nie i całosć bezie od tego czy ten poduł 
jest czy go nie ma to bezie mzoąn zrobic podpakiet typu 
mozilla-component-editor (albo coś koło takiehgo). Jeżli będzie podobnie z 
innymi komponntami to wydaje się że miałoby sens zrobienie całej serii 
podpakietów mozilla-component-*.

Z drugiej strony jeżeli w pmięć wpada komponent do edycji, a aplikacja
edycji nie wspiera to coś musi decydować, że powinno być to załadowane i
wygląda, że jest to nieporawna decyzja i/lub powiązania między modułami są
sztywne, a cała modularyzacja jest iluzją. Sprawdzenie czy
zasygnalizowanie tego ludziom od mozilli mogłoby też być ciekawe (Arek
masz tu już jakieś kontakty .. spróbuj zagadnąć o to też :).

No i kolejne pytanie które mi się jeszcze ciśnie jako konsekwencja
powyższego to kiedy są ładowane te komponenty ?
Czy przy starcie czy dopiero w momencie kiedy są potrzebne ? Wygląda że
działa to przy starcie, a powinno być raczej kompletnie dynamicznie (wtedy
kiedy jest to dopiero potrzebne). Jeżeli miało to działać dynamicznie to
także pownno działać wyładowywanie modułów nieużywanych i zwalnanie przez
nie zajmowanej pamieci. O ile ten mechaniz działałby poprawnie (a wygląda 
że nie działa) to w ten sposób mogłoby się okazać, że na starcie jednak
mozilla czy galeon zajmowałyby mniej pamięci i miałyby duże szanse
utrzymanie odczuwalnie mniejszego zapotrzebowania na pamieć w trakcie
dalszego działania.

Tutaj sytuacja mogłaby bardzo prosto mieć związek z np. libcookie.so. O
ile ktoś w konfiguracji ma zaznaczone że chce ignorować cookies to
zagladając do pamieci apliakcji takiej jak mozilla czy galeon nie powinno
się tam zobaczyć tego modułu (czyż nie ?).

Przykładowo w tej chwili u mnie z galeonem wygląda to tak:

$ pmap 24636 | tail -1
mapped:   61728 KB writable/private: 34452 KB shared: 300 KB

co jak widac wcale małym kawłakiem pamieci nie jest, a potencjalnie przy
lepszej gospodarce modułami mogłoby chyba to lepiej jednak wyglądać (?).

To tyle z wniosków jakie mi się tu nauwać jak dzisiaj się zacząłm temu
przyglądać z pmapem w ręku.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*