Java a nativní paměť

Hlavně je podle jména (a keců překladavče) jasné, že se jedná o věc nepřenosnou - ne na všech JVM je k dispozici, ne na všech platformách.

to P.S. je zábavné a smutné současně: normální aplikace by tohle neměla nikdy používat a Java měla od počátku důraz na to, aby aplikace v ní neměly problémy s pamětí. Takže kompilátor jen dělá svou práci a autorovi to vadí.

Spíše bych pochopil kritiku, že to tam vůbec je...

No škoda, že se u toho nedá použít RAII ;) - prostě JAVA

"Java měla od počátku důraz na to, aby aplikace v ní neměly problémy s pamětí"

Super vtip, i když obavám se, že autor to myslel vážně. Asi v Javě víc než Hello world ještě nenapsal.

@4: Taky pobavilo, už zase utírám monitor od kafe.

@zboj
v akej konkretnej situacii sa vam podarilo Unsafe pouzit?

Urychlení (de)serializace objektů.

jo a este: bolo by dobre povedat, ze to bezi len na sun/oracle javach, lebo mame aj javu od ibm alebo starsie jrockity a tam moze dojst k necakanym prekvapeniam

Clanek by se mohl jmenovat "Prasime v Jave, aneb chceme programovat v Jave jako v C++ a je nam to jedno".

Pouziti JNI/JNA/PInvoke stoprocentne zajisti, ze program bude neprenositelny a s velkou pravdepodobnosti zajisti i to, ze za deset let nebude zkompilovatelny ani na HW platforme, pro kterou byl puvodne urcen (empiricka zkusenost).

sun.misc.Unsafe je taky neprenositelny, navic clovek musi byt opravdu hodne zoufaly, aby to melo nejaky vetsi efekt. Vetsina tech veci ma svou prenositelnou variantu. Napriklad pro tu (de)serializaci je mnohem vyhodnejsi pouzit nektereho z potomku ByteBufferu.

Urychlení (de)serializace objektů je docela obecné... je to něco obdobného co dělá xstream?
http://svn.codehaus.org/xstream/trunk/xstream/src/java/com/thoughtworks/xstream/converters/reflection/SunUnsafeReflectionProvider.java

Jinak Unsafe používá pro zrychlení například i guava (dříve google collections) pro rychlejší porovnávání obsahu polí.

@9
Rozumné knihovny to dělají tak, že zkusí Unsafe a pokud není k dispozici, tak holt to udělají "čistě" a přenositelně. Viz ten zmiňovaný XStream - ten zdroják doporučuji, je z něj vidět kde je ten performance problém a že buffery opravdu, ale opravdu nepomůžou...

@podlesh: Konečně rozumný komentář místo blábolů :) Možná místo "rozumné knihovny" bych řekl přímo "rozumní vývojáři".

@ded.kenedy Zajímavé, že ti nejlepší vývojáři píšící rozsáhlé efektivní knihovny takto "prasí". Však taky poznamenávám, že to není pro každého. Kdo neví, jak přesně to funguje, měl by se tomu úplně vyhnout. Případně zůstat u Basicu ;)

@zboj: Co myslíte tím Basicem?
Například ve FreeBASICU si můžete zaprasit tak ,že se o tom v Javě nikomu ani nesnilo...

@11 Zrovna pred pulrokem jsem resil, jestli ma smysl pouzit buffery nebo unsafe pro aplikaci intenzivne pracujici s daty a vysledek byl temer nemeritelny, stezi v jednotkach ms. Nejvetsi bottleneck byl (jako obvykle) IO.

@13 Jo, ti bajecni vyvojari nebudou muset dnes napsane aplikace za deset let pouzivat nebo snad supportovat a tak, stejne jako ty, muzou dal s klidem v dusi uctivat fetis rychlosti, aniz by je trapilo, ze casem kvuli temto nedokumentovanym funkcim, jejich vytvor nepujde spustit nebo prelozit.

Ja by som bol strasne zvedavy ako autor ziskal udaj kolko je percentualne expertov na Javu zo vsetkych Java programatorov. Ako sa da vobec k takemu konkretnemu cislu (2-3%) vobec dostat? Zauradoval postup "pozrel som sa do stropu s prstom v nose a vymyslel si bulharsku konstantu"?

este mi napada, aka je u vas performance gain voci kniznici kryo? ta tiez serializuje, velmi rychlo, a volitelne pouziva unsafe.

Hezky clanek na toto tema;
http://mishadoff.github.io/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/

Padly zde dve protichudne informace:
1.) Unsafe se pouziva tam, kde zasobniky nepomuzou
2.) Delal jsem testy a rozdily zasobniku versus Unsafe a rozdily byly minimalni

Tak ted nevim teda.. :-)

@ded.kenedy
Muzesa postnout, jakym zpusobem jsi testoval?

Mozno na niektore pripady by bolo lepsie a hlavne prenositelnejsie pouzit ByteBuffer.allo­cateDirect?