Diky moc za tenhle serial. Delam jednu docela slozitou knihovnu (www.mapdb.org) a dobre vysvetlene JVM internals se dost hodi.
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.
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...
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.
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...
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?