Vlákno názorů k článku Pohled pod kapotu JVM – základy optimalizace aplikací naprogramovaných v Javě od Palo - Uha to kolko je tu specialistov na generovanie...
-
> Poznate 'javac'?
LOL> Na co to ludia pouzivate?
Například na https://is.muni.cz/th/374423/fi_b/ . -
Ano, logovací frameworky a klasický debugger jsou k podobnému účelu, ale poskytnou na činnost programu trochu jiný pohled. Samozřejmě vím, co dělá iadd (Koneckonců, bez aspoň základní specifikace bych s tím nezvládl vůbec nic, protože bych nevěděl ani co chce na operand stacku.), ale chtěl jsem řict, že pomocí AspectJ bych ten nástroj asi opravdu nenapsal.
-
Pavel TišnovskýZlatý podporovatelTreba AOP je na tom do znacne miry zalozeno; klasicky priklad je pridani logovani na vstupnich bodech metod, hodi se to pro testovani (fault injection testing...), opravu chybnych binarnich knihoven atd.
Taky spousta optimalizaci zacne davat smysl az kdyz clovek porozumi bajtkodu (ale to stejne plati pro C/C++ a instrukcni sadu daneho mikroprocesoru).
Pokud bych mel brat % Java vyvojaru, co to znaji a vyuzivaji, tak je to asi relativne male cislo, coz je na druhou stranu dobre :)
-
Palo (neregistrovaný)
Takze mozem zabudnut na cele komplikovanie kniznice a pouzit rovno AspectJ.
V zivote som nic nepozeral na uroven bytekodu. To ze autoboxing je narocny, dokonca niekedy aj vypocet hash-u, na to nepotrebujem pozerat na bytekod.
Vacsina optimalizacii sa aj tak skryva v algoritme obvykle pamat vs. rychlost. -
Pavel TišnovskýZlatý podporovatel
Urcite, pokud AspectJ vyhovuje pro dany ukol, proc ho nepouzit...
Ono tech zposobu optimalizace je cela rada a spousta jich souvisi s low-level vecmi. Fakt zalezi na zadani, jestli zakaznikovi je jedno co pouzije za masinu (ale i tady se optimalizacim neda vyhnout, spis zacinam mit despekt k lidem, co resi problem tak, ze na nej hodi silnejsi HW ;-), nebo jsou akceptacni testy nastaveny i s ohledem na vykon, dobu behu/cas odpovedi atd.
-
Palo (neregistrovaný)
Hodit na to silnejsie zelezo je obvykle lacnejsi a istejsi sposob optimalizacie so zarucenym vysledkom nez najimat programatorov castokrat za nasobne vyssiu cenu ako je HW s neistym vysledkom. Tiez to nemam rad ale chapem klientov.
Vacsinou ja sa stretavam so zle vytvorenou architekturou, zlym vyberom frameworkov, zlym vyberov produktov. SQL vs noSQL, IO operacie, messaging, transakcie, ... tam si s bajtkodom nepomozete.
Zly vyber Collection, nepouzivanie late inicializacie, synchronizacia to robim spamati bez bytekodu. -
Pavel TišnovskýZlatý podporovatel
jj chapu, no klienti jsou dost ruzni i ruzne projekty (navic hazeni silnejsiho HW na problem pokulhava v oblasti smartphonum at nechodime moc daleko).
Taky jde o to, jaky je obchodni model: prima zakazka vs napriklad nabidka produktu s nejrychlejsim messagingem, HTC, HPC atd. atd. V kazdem pripade na ten bajtkod vetsinou drive ci pozdeji dochazi :-) Ono se staci podivat na zoubek treba gridu nebo i nejake te noSQL databazi v Jave - tam je pekne videt, jak to borci optimalizovali se znalosti interni prace JVM.
-
Pavel TišnovskýZlatý podporovatel
Vsak ano, na kazde vrstve se resi trosku jine optimalizace. My si hrajeme s C1/C2 JITy aby to borci s noSQL, Hadoop atd. meli jednodussi, vy pouzijete napriklad hotovy Hadoop a nemusite znovuvynalezat mapreduce, nekdo dalsi Vasi aplikaci bude jednuse volat pres WS apod.
Nicmene i v Jave se narazi na problemy s vykonnosti odladenych algoritmu, ktere mnohdy jdou velmi jednoduse vyresit se znalosti bajtkodu (tableswitch vs. lookupswitch, zmineny autoboxing, neoptimalni pristup k polim, vubec uvedomeni si, jak vypada i ten nejjednodussi objekt na halde atd.)
-
Podobně by asi pomohlo zkusit si programovat ve starší verzi Javy. J2ME mi (i bez znalosti bytecode) pomohlo pochopit, jak jsou implementována generika. Trošku nečekaně mi pomohlo i PHP, kde jsem se pokoušel udělat inner class (plus přístup k privátním členům) a došel jsem k velmi podobnému řešení. Ale spíš než PHP bych asi doporučil Javu 1.0, ta prý taky nemá inner classes.
Ono to vůbec vypadá, že bytecode byl navržen tak, aby odpovídal první verzi Javy, a od té doby se už moc neměnil. Jen nějaké drobné změny (invokenonvirtual->invokespecial když byl problém, změna v lcd/ldcw, změny v memory modelu, StackMapTable pro rychlejší verifikaci v JVM) a pak snad až invokedynamic - snad první výraznější novinka, která vyloženě přidává něco nového.
