Proč je Java pomalá a problémová?

[Pavel Tisnovsky]

A jak dlouho se bude jeste vyvijet nez bude pouzitelny?

google. nastroje vyhledavani. a nastavit datum "do". nechce se mi hledat prvni datum, ale vsadil bych si snad uz nekde okolo 1996

1. 2. 2001 - The Java HotSpot VM provides a garbage collector that .....

Vyvoj zacal vloni, az se objevil HW, kde to ma smysl, proc se ptas? GC v Jave a vlastne i vsechny GC jsou tady s nami dele nez dnes mainstreamove jazyky, neustale se vsak upravuji tak, aby reflektovaly vlastnosti noveho HW.

ptam se proto, ze myty o funkcnim pausless garbage collectoru jsou na poradu dne snad vic jak 15 let. existoval and uz od prvni verze jvm jenze byl v experimentalnim stavu, takze na produkcni nasazeni nepouzitelny - mem corruption asi kvuli spatnemu zamykani, cekem caste pady a zridka kdy i nejaky ten livelock nebo deadlock.

mimo to, kdyz uz nahodou mel svetlou chvilku a fungoval, tak mel ze vsech GC nejhorsi skalovatelnost. s lineranim rustem vytizeni aplikace vytezoval HW exponencialne, takze byl naprosto neplanovatelne nepredvidatelny.

Vim, ale toto je neco jineho, jmenuje se to Shenandoah GC a delaji na tom dva kolegove z Red Hatu (ja to jenom testuju .
http://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/
http://rkennke.wordpress.com/2013/06/18/shenandoah-gc-an-overview/

Prijd pristi rok na Developer konferenci do Brna, mela by tam o nem byt prednaska

[Reklama]

[Mirek Prýmek]

Aha jasny, ono to asi pro kratkodobe procesy je jednodussi, hlavne kdyz neni zapotrebi resit cyklicke reference

Pravě. Přesně o to mi šlo - že Erlang jako jazyk má prostě vlastnosti, které výrazně zjednodušují konstrukci GC a 1) umožňují postupy, které by jinak nešly 2) jednoduché postupy mají díky nim překvapivě dobré výsledky

Když je program správně napsaný - tj. long-lived procesy nebobtnají, procesů je spousta a většina z nich žije krátce, je z toho vlastně zadarmo inkrementální GC s minimálním dopadem na odezvu a žádným globálním stopem. Docela hezky jsou základní principy a vlastnosti popsané tady: http://prog21.dadgum.com/16.html

[Pavel Tisnovsky]

Aha jasny, ono to asi pro kratkodobe procesy je jednodussi, hlavne kdyz neni zapotrebi resit cyklicke reference

Pravě. Přesně o to mi šlo - že Erlang jako jazyk má prostě vlastnosti, které výrazně zjednodušují konstrukci GC a 1) umožňují postupy, které by jinak nešly 2) jednoduché postupy mají díky nim překvapivě dobré výsledky

Když je program správně napsaný - tj. long-lived procesy nebobtnají, procesů je spousta a většina z nich žije krátce, je z toho vlastně zadarmo inkrementální GC s minimálním dopadem na odezvu a žádným globálním stopem. Docela hezky jsou základní principy a vlastnosti popsané tady: http://prog21.dadgum.com/16.html

pekne vysvetlene dik moc za odkaz. Z JVM jazyku se nejvice odlisuje Clojure, a tam by se asi mohlo o necem podobnem uvazovat (izolace pameti pro funkce, "futures" atd.), ale jestli na to nekdo bude mit silu a chut.... tezko rict.

[Mirek Prýmek]

Z JVM jazyku se nejvice odlisuje Clojure, a tam by se asi mohlo o necem podobnem uvazovat (izolace pameti pro funkce, "futures" atd.), ale jestli na to nekdo bude mit silu a chut.... tezko rict.

Na nej jsem prave myslel. Akoratze porad tam zustava moznost kooperace s normalnimi javovymi metodami, takze tim to asi docela pada, ne?

[omg]

A jak dlouho se bude jeste vyvijet nez bude pouzitelny?

google. nastroje vyhledavani. a nastavit datum "do". nechce se mi hledat prvni datum, ale vsadil bych si snad uz nekde okolo 1996

1. 2. 2001 - The Java HotSpot VM provides a garbage collector that .....

Vyvoj zacal vloni, az se objevil HW, kde to ma smysl, proc se ptas? GC v Jave a vlastne i vsechny GC jsou tady s nami dele nez dnes mainstreamove jazyky, neustale se vsak upravuji tak, aby reflektovaly vlastnosti noveho HW.

ptam se proto, ze myty o funkcnim pausless garbage collectoru jsou na poradu dne snad vic jak 15 let. existoval and uz od prvni verze jvm jenze byl v experimentalnim stavu, takze na produkcni nasazeni nepouzitelny - mem corruption asi kvuli spatnemu zamykani, cekem caste pady a zridka kdy i nejaky ten livelock nebo deadlock.

mimo to, kdyz uz nahodou mel svetlou chvilku a fungoval, tak mel ze vsech GC nejhorsi skalovatelnost. s lineranim rustem vytizeni aplikace vytezoval HW exponencialne, takze byl naprosto neplanovatelne nepredvidatelny.

Vim, ale toto je neco jineho, jmenuje se to Shenandoah GC a delaji na tom dva kolegove z Red Hatu (ja to jenom testuju .
http://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/
http://rkennke.wordpress.com/2013/06/18/shenandoah-gc-an-overview/

Prijd pristi rok na Developer konferenci do Brna, mela by tam o nem byt prednaska

Diky za info. Muzu jeste dotaz k tomu, jak si myslel s tim, ze se "ted" objevil hardware, kde to ma smysl? Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.

Jeste je teda moznost, ze si myslel mobily a tam by pausless mel skutecne opodstatneni i se vsemi puvodnimi nedostatky. 20MB aplikace s 100MB daty co ma k dispozici 2GB a je potreba, aby se "neustale hejbala".

[Reklama]

[shini]

+ se nechava prace na GC i u objektu, jejichz zivotnost je evidentne jen mala - blok, metoda

Zrovne tohle dokaze runtime zoptimalizovat diky escape analyze, kratce zijici objekty jdou na stack, nektere se ani nemusi alokovat cele, tj tlak na GC v nekterych pripadech dost vyrazne klesa.

[Pavel Tisnovsky]

+ se nechava prace na GC i u objektu, jejichz zivotnost je evidentne jen mala - blok, metoda

Zrovne tohle dokaze runtime zoptimalizovat diky escape analyze, kratce zijici objekty jdou na stack, nektere se ani nemusi alokovat cele, tj tlak na GC v nekterych pripadech dost vyrazne klesa.

To jo, ale ja myslel (mel jsem to napsat jasneji) podporu v bytecode - tam neexistuje zadna instrukce typu delete (opak k new, newarray, anewarray a multianewarray), kterou by prekladac mohl (pokud by existovala) davat na konec metod/do finally/ja nevim kam jeste u objektu, jimz jasne a na zaklade compile-time analyzy konci zivotnost. Teoreticky by to mohlo snizit naroky na pamet, ale asi to nikdo nezkousel. On vubec bytecode moc JITu nepomaha, mohl by pridavat ruzne hinty ke spouste vecem, co se pri prekladu ztrati :-) ale proste takto to bylo navrzene a asi se dockame max. nejakych dalsich metadat jestli vubec.

[Pavel Tisnovsky]

Diky za info. Muzu jeste dotaz k tomu, jak si myslel s tim, ze se "ted" objevil hardware, kde to ma smysl? Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.

Jeste je teda moznost, ze si myslel mobily a tam by pausless mel skutecne opodstatneni i se vsemi puvodnimi nedostatky. 20MB aplikace s 100MB daty co ma k dispozici 2GB a je potreba, aby se "neustale hejbala".

No obavam se, ze je to presne pro opacne spektrum HW ;-) Je to cileno na servery s mnoha CPU a obrovskymi heapy (takze "enterprise" nesmysly a mracky), s kteryma maji soucasne GC problemy - dlouhe casy pri full GC + navic ten pitomej stop-the-world. Shenandoah by toto *mel* vylepsit, zatim vyvojova verze v benchmarcich (SPECjbb hlavne) dosahuje +- stejne vykonnosti jako ParallelGC, ale je to fakt vyvojova verze, ktera alespon nepada a neleakuje, coz je docela uspech ;-)

[omg]

Diky za info. Muzu jeste dotaz k tomu, jak si myslel s tim, ze se "ted" objevil hardware, kde to ma smysl? Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.

Jeste je teda moznost, ze si myslel mobily a tam by pausless mel skutecne opodstatneni i se vsemi puvodnimi nedostatky. 20MB aplikace s 100MB daty co ma k dispozici 2GB a je potreba, aby se "neustale hejbala".

No obavam se, ze je to presne pro opacne spektrum HW ;-) Je to cileno na servery s mnoha CPU a obrovskymi heapy (takze "enterprise" nesmysly a mracky), s kteryma maji soucasne GC problemy - dlouhe casy pri full GC + navic ten pitomej stop-the-world. Shenandoah by toto *mel* vylepsit, zatim vyvojova verze v benchmarcich (SPECjbb hlavne) dosahuje +- stejne vykonnosti jako ParallelGC, ale je to fakt vyvojova verze, ktera alespon nepada a neleakuje, coz je docela uspech ;-)

rok 2007, 64 vlaken, UltraSPARC T2 (Niagara 2) 1GHz - 1.6GHz
rok 2007, 64 vlaken, UltraSPARC T2 Plus (Victoria Falls) 1.2GHz - 1.6GHz
rok 2010, 128 vlaken SPARC T3 (Rainbow Falls), 1.6GHz

rok 2009 http://www.sec.gov/Archives/edgar/data/709519/000119312509183962/d10k.htm
ITEM 6.    SELECTED FINANCIAL DATA
                                                        2009 Dollars               %
Income (loss) before taxes              (2,183    )          (19.1    )
rok 2010 odprodej Sun spolecnosti Oracle

[Filip Jirsák]

S čím to porovnávají?

Nemluvím o žádných metrikách, čistě o tom, že admini, kteří se o javové aplikace starají, na to docela nadávají. Ale je to čistě subjektivní a vzorek lidí, který jsem slyšel, je samozřejmě malý. Právě proto by mě zajímalo, jestli třeba neproběhl nějaký výzkum ala "spokojenost adminů s provozováním javových aplikací"

Já jsem se taky neptal na metriky. Ono je totiž také možné (a řekl bych, že pravděpodobnější), že ty vlastnosti jsou typické pro ten typ aplikací, které spravují – bez ohledu na to, v čem jsou napsané.

[Pavel Tisnovsky]

Diky za info. Muzu jeste dotaz k tomu, jak si myslel s tim, ze se "ted" objevil hardware, kde to ma smysl? Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.

Jeste je teda moznost, ze si myslel mobily a tam by pausless mel skutecne opodstatneni i se vsemi puvodnimi nedostatky. 20MB aplikace s 100MB daty co ma k dispozici 2GB a je potreba, aby se "neustale hejbala".

No obavam se, ze je to presne pro opacne spektrum HW ;-) Je to cileno na servery s mnoha CPU a obrovskymi heapy (takze "enterprise" nesmysly a mracky), s kteryma maji soucasne GC problemy - dlouhe casy pri full GC + navic ten pitomej stop-the-world. Shenandoah by toto *mel* vylepsit, zatim vyvojova verze v benchmarcich (SPECjbb hlavne) dosahuje +- stejne vykonnosti jako ParallelGC, ale je to fakt vyvojova verze, ktera alespon nepada a neleakuje, coz je docela uspech ;-)

rok 2007, 64 vlaken, UltraSPARC T2 (Niagara 2) 1GHz - 1.6GHz
rok 2007, 64 vlaken, UltraSPARC T2 Plus (Victoria Falls) 1.2GHz - 1.6GHz
rok 2010, 128 vlaken SPARC T3 (Rainbow Falls), 1.6GHz

rok 2009 http://www.sec.gov/Archives/edgar/data/709519/000119312509183962/d10k.htm
ITEM 6.    SELECTED FINANCIAL DATA
                                                        2009 Dollars               %
Income (loss) before taxes              (2,183    )          (19.1    )
rok 2010 odprodej Sun spolecnosti Oracle

Jenze Sun uz v te dobe nevedel, kam smerovat, na co se zamerit. Proste udelali spoustu prehmatu a nektery jejich vize se uskutecnily treba o deset let pozdeji (tenky klienti napriklad). Zpomaleni vyvoje Javy zacalo uz nekdy v 2008...

[omg]

Asi to bude dusledek katovani kostu. Spousta aplikace v kombinaci s vetsinou existujicich GC pak dopada bez ohledu na jazyk/vm tak, ze je v beznem provozu tahana s nedostatecnou rezervou pro mimoradnou zatez, protoze pri mimoradne zatezi se jim krivka skalovatelnosti zalomi a "zrychli smrt". reseni to ale ma jen o nej nikdo jeste nezavadil, protoze je komplexni a z pohledu IT "mezioborove". zatim si to necham jako obchodni tajemstvi.

[omg]

Jenze Sun uz v te dobe nevedel, kam smerovat, na co se zamerit. Proste udelali spoustu prehmatu a nektery jejich vize se uskutecnily treba o deset let pozdeji (tenky klienti napriklad). Zpomaleni vyvoje Javy zacalo uz nekdy v 2008...

rok 2005, 32 vlaken, UltraSPARC T1 (Niagara) 1 - 1.4 GHz

staci takhle? kdyz ostatni dva narazili na frekvencni fyzikalni strop a zacali pridavat jadra, tak se Sun neobtezoval k tomu frekvencnimu stropu dojit a rovnou udelal to co ostatni dva a naskocil na vice vlaken akorat jich pridal jeste vic, aby se dorovnal. a trh to asi vnimal jako menecennost.

[Pavel Tisnovsky]

Jenze Sun uz v te dobe nevedel, kam smerovat, na co se zamerit. Proste udelali spoustu prehmatu a nektery jejich vize se uskutecnily treba o deset let pozdeji (tenky klienti napriklad). Zpomaleni vyvoje Javy zacalo uz nekdy v 2008...

rok 2005, 32 vlaken, UltraSPARC T1 (Niagara) 1 - 1.4 GHz

staci takhle? kdyz ostatni dva narazili na frekvencni fyzikalni strop a zacali pridavat jadra, tak se Sun neobtezoval k tomu frekvencnimu stropu dojit a rovnou udelal to co ostatni dva a naskocil na vice vlaken akorat jich pridal jeste vic, aby se dorovnal. a trh to asi vnimal jako menecennost.

No jim se taky nepodaril vic prosadit Solaris, takze ani nemohli moc prodavat boxy se SPARCama (teda samozrejme je prodavali, minimalne v Brne vim o trech velkych firmach co Solaris+Sun HW nasazovali, ale proti te hromade jinych reseni to asi bylo dost slaby). Ale to je hlavne muj pocit, chtelo by to nejaky grafy s porovnanim nasazeni Solarisu, Linuxu, dalsich Unixu a Windows Server ed. mezi dejme tomu roku 2000-2012 (nemam po ruce :/)

[andy]

Celkom by ma zaujimalo, kolko diskutujucich tu ma realne skusenosti s velkymi enterprise systemami. Myslim tym napr. aplikacie operatorov, velkych poistovni atp.
Ale nie ze kamarat kamarata spravuje taky system.. Okrem toho spravcovia aj tak do toho az tak nevidia. Potom sa stane, ze obcas ma aplikacia nejaku chybu, ktora vobec nesuvisi s tym na com bezi a uz to ma ta platforma zratane..

Ohladne sunu ja to vidim tak, ze pre mensie firmy bol zbytocne drahy (oproti napr. wintel platforme) a tie co to skutocne potrebovali uz davno bezali na ibm.