SG.hu·2005. március 26.

A Sun a Java gyorsításán dolgozik

A Sun Microsystems külön projektet indított a Java alkalmazások memóriakezelésének, valamint a több alkalmazás egyidejű futtatásakor fellépő sebességbeli problémák javítására.

A Multi-Tasking Virtual Machine (MVM) prototípusát a Sun barcelonai laboratóriumában fejlesztik, és a vállalat honlapjának tanúsága szerint az új futtatókörnyezet elsődleges feladata a több Java alkalmazás futtatása körüli gondok enyhítése. A szakemberek szerint az MVM - amely a Java HotSpot Virtual Machine, valamint annak kliens fordítóján alapul - a több alkalmazás egyidejű futtatása révén növeli a Java skálázhatóságát, és csökkentheti a memóriaigényt. Példa erre Matthew Schmidt kijelentése, aki Java fejlesztőként a JavaLobby felhasználói közösség alelnöki posztját tölti be.

"Úgy vélem, az MVM megoldást nyújthat a Java egyik legnagyobb problémájára, amit a különösen nagy memóriaigény jelent több alkalmazás egyidejű futtatásánál" - jelentette ki Schmidt, összegezve az új fejlesztéssel kapcsolatos elvárásokat. Elmondása szerint a Java alkalmazások méretükhöz képest sok memóriát foglalnak le, és a probléma több alkalmazás egyidejű futtatásának esetében jóval nagyobb kellemetlenséget jelent.

A Sun fejlesztőcsapata időközben nyilvánosságra hozta a legfontosabb újítások egyikét. Ezek szerint az MVM lehetővé tenné, hogy a különböző Java alkalmazások egy virtuális gépen belül fussanak le - jelenleg ugyanis minden egyes alkalmazás saját virtuális gépet (Java Virtual Machine, JVM) igényel a futtatáshoz. "Az MVM egy operációs rendszerhez hasonlóan működik: egyidejűleg több alkalmazást is elindíthatunk, amelyek megosztoznak az erőforrásokon" - jelentette ki Schmidt.

Az új fejlesztés nagyobb skálázhatóság és kedvezőbb sebesség érdekében a J2EE 1.3.1-es verziójához igazodik - a Java 2 Platform Standard Edition egyes vélemények szerint nem lenne a legjobb választás, a vállalat azonban még nem hozta meg a végső döntést.

Kapcsolódó cikkek és linkek

30 éves a Java, és még mindig van benne erõ A közösség fejlesztheti tovább a Java EE-t A Java sérülékenysége miatt van a legtöbb támadás Dollármilliárdokat követel az Oracle a Google-tól Java-hiányosságokat használnak ki a kiberbûnözõk Google: JavaScript eszközkészlet fejlesztõknek Teljesen nyílt lesz a Java Nyílt Javát kér az egykori Sun-vezér Sun Microsystems ↗

Hozzászólások

Jelentkezz be a hozzászóláshoz.

Ne haragudj, de a szakmai vita érveket szokott jelenteni, nem üres kijelentéseket!

"Persze a linux kernel c-ben írása mellett ez bõven elég érv!"

Termeszetesen performance okokbol kifolyolag irjak a kernelt C-ben. Ez igy van a Windowsnal is. Pl. egy O(1) utemezot hatkeonyabb C-ben, mint C++-ban irni.

Na ebben nagyjából egyet értünk, kivéve a memória használot, bár meg kell jegyeznem korábban a sebességet hangsúlyoztad! ;-) Mivel foglal több memóriát egy c++ kód? Virtuális függvényeket tartalmazó objektumonként egy pointernyivel? Vagy mire gondolsz? Nem fogalmazol túl konkrétan... Jobb hordozhatóság miatt, egzotikus platformok bugos, rosszul optimalizáló fordítóin kívül én nem igazán tudok érvet a c mellett a c++ ellenében. Persze a linux kernel c-ben írása mellett ez bõven elég érv!

Nem soroltam a C++ egy kategóriába a .NET nyelvekkel. A C++ az mint te is tudod native kódot eredményez (kivéve a .NET managed C++ át), és álltalában 20% vagy attól is gyorsabban fut a .NET féle kódtol. Csak azt akartam kihangsúlyozni, hogy a C++ már nincs annyira gépközelben mint a C, vagyis itt nem annyira sebesség gondok voltak a fejemben, mert C++ ban lehet irni C gyorsaságú kódot, viszont a C++ kód alapjában sokkal több darabot szakít le a gépbõl, gondolok itt mindenek elõtt a memoriára stb. Persze C++ ban esetleg tisztább kódot irnának és jobban kezelhetõt, de szerintem egy OS kernelnek ez nem az elsõszámu prioritása. Az én "anyanyelvem" a C és a C++ meg a C# egyaránt és ez miatt egyiket sem részesíteném elõnyben, de mindenesetre tudom, hogy mikor melyiket használnám.

És persze, hogy lehet OS-t irni Javaban is, de a kérdés, hogy megéri e?

Nem írtál konkrétumokat, így vegyük sorra:

member függvény hívások: ez csak egyszerû szintaktikai különbség, ha c++-ben ezt irod:

object.function();

a hívás assembly-ben már ugyanaz, mintha c-ben ezt irnád:

function(Object* this);

virtuális függvények:

Ennek mint írtam van kis overheadje, de nem igazán létezik effektívebb módszer, kivéve speciális esetekben, nagyjából így mûködik:

ugye egy class ami tartalmaz virtuális függvényt annak van egy utolsó nem látható membere, egy pointer a virtuális függvényeinek címét tartalmazó táblára. Tehat egy kétszeres indirekción keresztül (csak memóriaolvasás) történik, az nem egy vészes dolog. Egy hagyományos - tehát nem inlineolt függvényhez képest - a cache találat a leglényegesebb tényezõ, mind code, mind adat cache részérõl. Magyarán, ha egy függvény nem inlineolt, és az ugrótábla benne van az adat cache-ben, akkor nagyon minimális a plusz mûvelet amit igényel, ha érdekel azt is kirészletezhetem, hogy milyen alternatíváid lehetnének, de egy másik hozzászólásban, így is túl hosszú leszek...

template-ek: ezekkel egy függvény-t class-t tudsz sokféle típusra legyártani, de ez sebességben nem jelent overhead-et, mivel külön külön legyártja õket az összes használt típusra, egy egyszerû nem túl gyakorlatias példa:

template <class T>
void SetOne(T &Val)
{
Val= 1;
}

függvény esetén ha használod int-el és float-al, akkor legyártódik 2 féle verzió, így pont ugyanaz, mintha te írtad volna meg õket mindkét típusra. Természetesen ezt bármly normális fordító ki-inlineolja, és gépi kódban már nem lesz semmiféle függvényhívásod, egyszerûen egy memóriacímbe, vagy regiszterbe tölti direkt módon az int vagy float 1-et.

"tankönyvszagú kijelentésekkel szeretnék vitába szállni."

Hat hajra.

Az utolsó mondatod nem tudom, nekem szól-e, ha igen félre vagyok értve...
A miben írj oprendzsert témához én nem szóltam hozzá, csupán idéztem BlackRose-tól, és engem a mondatának az a része érdekelt, hogy sebesség terén a c++-t egy kategóriába sorolta a .NET alapú managed nyelvekkel. Csupán az "az objektum orientalt elvekhez kapcsolodo absztrakt nyelvi elemek valoban extra overheaddel jarnak" tankönyvszagú kijelentésekkel szeretnék vitába szállni.

Jogos, de mivel futási idõben történik, az optimalizálása szánt idõ erõssen korlátozott, ezért nem hiszem, hogy beérik, vagy lehagynák a natív gépi kódot fordító nyelveket. Persze java-nál ott vannak még más sebességet visszafogó tényezõk is, mint automatikus tömb túlcímzés vizsgálat, vagy, hogy minden member függvény virtuális. Profile alapján optimalizálást egyébként a mai fejlett c++ fordítók is tudnak, az új intel compiller, ill a vc 2005 már támogatja.

a java virtális gép miatt önmagában nem kell lassabban futnia egy kódnak, sõt futhat gyorsabban is: a vm ugyanúgy gépi kódra fordít, csak futásidõben, ez viszont azt is jelenti, hogy futásidejû információja birtokában optimalizálhat. Egy statikus compilernek nem állnak rendelkezésre ezek az információk.

A mobiltelefonok java futtatójával az a baj, hogy még nagyon primitívek, többnyire egyszerûen interpreter módban mûködnek, természetes hogy lassúak. Sokat azért nem kell várni, hogy az asztali gépeken alkalmazott java futtatók techinkái leszivárogjanak a mobiltelefonok szintjére.

hogy pontosítsak: nem, nem keverem a VMS-t és a clustert (ég és föld), csak fáradt vagyok átvezetéseket írni az egyes mondatok között :)

További bejegyzések a fórumban...