Názory k článku Pohled pod kapotu JVM - průchod hodnotami atributů objektů uložených na haldě (heapu)
-
Jan Kotek (neregistrovaný)
Diky moc za tenhle serial. Delam jednu docela slozitou knihovnu (www.mapdb.org) a dobre vysvetlene JVM internals se dost hodi.
-
Pavel TišnovskýZlatý podporovatelTa knihovna vypada dost zajimave, budu se v tom muset nekdy trosku povrtat :) protoze jestli to fakt zvlada i transakce...
-
Ivan (neregistrovaný)
Vim, ze je to trochu offtopic dataz, ale existuje neco podobneho pro pripad kdyz uz je JVM "mrtva"? Uz jsem nekolikrat narazil na situaci kdyz uz jsem nemel k dispozici nic jineho nez coredump JVM mel jsem najit duvod proc to umrelo.
Nekde na strankach HP jsem sice nasel nejaky navod jak pomoci gdb ziskat z coredumpu nejake informace o Java Heapu. Bohuzel jsem se s tim ale moc daleko nedostal.
-
Pavel TišnovskýZlatý podporovatel
Hmm tam je to horsi. Minimalne by se mel *nekde* (zalezi na konfiguraci a konkretnim zpusobu spusteni javy) vygenerovat soubor hs_err*.log se stack tracem jednotlivych vlaken, z toho se nekdy daji vycist rozumne informace.
Nebo udelat agenta, ktery udela heap trace tesne pred spadnutim JVM - tento agent v podstate nic nezabere v pameti (doslova par kilobajtu) a vykonove taky nic neohrozi...
-
Rax (neregistrovaný)
Mít stringy uvnitř aplikace v UTF-8 je produkt chovanců Chocholouška, protože se u každého znaku musí pracně zjišťovat, kolik byte vlastně má a proto se UTF-8 používá jenom pro uložení dat mimo aplikaci, například do XML nebo do databáze.
Java by se s použitím UTF-8 tedy ještě zásadně zpomalila.
A pomalost Javy není ani náhodou způsobena tím že stringy mají dva byte na znak. -
Pokud budu vycházet z předpokladu, že nejčastějšími operacemi nad řetězci jsou kopírování, sčítání, porovnání řetězců a hledání podřetězce, tak ani při jedné z těchto operací se nemusí provádět zjišťování velikosti každého znaku v řetězci - naopak tyto operace budou rychlejší z důvodu téměř poloviční velikosti. Díky tomu můžete mít lepší využití CPU cache, můžete lépe využít operační paměť - velké množství řetězců se drží v různých caches.
-
Pavel TišnovskýZlatý podporovatel
Slo by to relativne jednoduse - projit JVM TI agentem pres vsechny char[] a otestovat, kolik je tam znaku > 127. To stejne s constant poolem.
Dokonce je mozny si upravit tridu String, StringBuffer a StringBuilder tak, aby namisto char[] pouzivala byte[] (protoze Stringy budou urcite ty tridy, kde se char[] vyuziva absolutne nejvic) a pri cteni/zapisu provadet prevod char->byte[] (UTF-8) a naopak. Ale bude to dost pomale rekl bych, ty posuny osmibitovych hodnot...
-
kvr (neregistrovaný)
Kdyby bylo v UTF-8 úplně všechno, tak ty konverze prakticky vypadnou.
Co by se zpomalilo, jsou locale aware parsery, maps, atd. a těch je IMHO minimum (z hlediska podílu na CPU). Nehledě na to, že ty by měly správně být Unicode32 aware a tedy pomalé už tak :-)S tou úpravou je to zajímavé, zkoušel to už někdo v praxi?
-
Pavel TišnovskýZlatý podporovatel
To by chtelo otestovat na realnych aplikacich. Pravda je, ze spousta javovskych aplikaci neustale pracuje s XML, takze s UTF-8, tam ty konverze asi budou hooodne bolet. Hmm na takovym aplikacnim serveru co generuje stovky XHTML stranek za hodinu...
-
Pavel TišnovskýZlatý podporovatel
Tak zatim jsem prisel na dve moznosti jak to vyuzit - bud si zkompilovat svoji OpenJDK s upravou tridy String nebo pres xbootclasspath tam nacpat svoji tridu String v runtime, coz vsak pravdepodobne nebude fungovat dokonale (kvuli constant poolu, ktery uz bude naplneny).
-
-
Pavel TišnovskýZlatý podporovatel
Jeste pro jistotu doplnim, ze pokud se znak do toho rozsahu 0x0000 az 0xffff (ted to hodne zjendodusuju) nevleze, tak se ve stringu pouzije dvojice znaku. Ale v nasich koncinach to neni az tak aktualni rekl bych:)
