"Szerinted a Java hatranya a tomb-hatarok ellenorzeseben es a GC-szunetben ki is merul, ezen tul a JVM teljesen kepes a mernokok es fordito altal optimalizalt C++ koddal egyenlo teljesitmenyt nyujtani."
Nem, nem csak a tömb határokról van szó, annál lényegesen több ellenőrzés van és az optimalizációkból is lényegesen több van. Érdemes OpenJDK forrást olvasni a témában, meglepően sok ilyen dolog van és sokat lehet tanulni is belőle, akár a C/C++, akár a Java részből.
Talán két éve mélyedtem el ebben, tényleg ezek adják a lassabb futás okát:
a, a runtime ellenőrzések, amely szinte lehetetlenné teszi, hogy véletlenül más memóriaterületre írj vagy olvass onnan;
b, a class és method szintű policy, amivel akár egy homokozón belüli homokozóban tudsz tartani egy hostile class-t;
c, a különféle GC algoritmusok és azok paraméterezése, amelyekkel különféle workload esetén különféle GC időket lehet mérni;
Minden más elhanyagolható ezekhez képest. A tömb túlcímzéssel azért szoktam példálózni, mert az a legegyszerűbben megérthető példa és általában erre se szoktak figyelni a fejlesztők... ha megnézel egy tetszőleges C/C++ programot, elvétve találsz benne tömb-túlcímzés ellenőrzést és natív kódban egy tömb írás egy memória írás helyett rögtön öt utasítássá válik... ennél egy fokkal veszélyesebb az, hogy sokszor típusellenőrzés sincs és sokszor a process-memória bármelyik részére írhat bárki.
Ezek a dolgok nem azért kerültek bele by-design a Java platformba, mert hátulgombolósok tervezték hátulgombolósoknak, hanem azért, mert az átlagnál jobb C/C++ fejlesztők is hajmeresztő hibákat ejtettek rendszeresen, amelyeket ezek a védelmi mechanizmusok teljes egészében ki tudnak védeni. Ennek nyilván ára van, de annak is, hogy kikerülöd ezeket, csak amíg a teljesítménycsökkenés egzaktul mérhető, addig a potenciálisan kihasználható hibák számára nincs egzakt mérés...
...az ügyfeled pedig nem biztos, hogy ennek ismeretében is ugyanúgy választana, hogy 3000 vagy 1000 dollárt költ havonta az adatbázis infrastruktúrára, amikor mondjuk egy 10 millió dolláros adathalmazon ül, mert kijöhet az ügyletből úgy, hogy megtakarított 5 év alatt 120 ezer dollárt és úgy is, hogy elbukott 10 millió dollárt, mert el tudták lopni az adatait.
Ezért például az UDF-et meg tudod majd oldani úgy, hogy nagyjából funkcionálisan azonosan működjön, mint Cassandra esetén, de ugyanazt a biztonsági szintet nem tudod elérni, amit Cassandra esetén a JVM ad. Ekkor a három lehetőségedből reálisan két lehetőséged lesz:
a, apró betűvel feltünteted, hogy az UDF egy komoly támadási vektor lehet;
b, körbetákolod mindenféle védelemmel, hogy ezen keresztül ne lehessen támadni a szoftvert;
c, beleteszed mindazt, amit a JVM-be tettek több száz emberév munkájával, de erre nem lesz egy individuális program esetén erőforrásod.
És ez általában igaz minden funkciójára a szoftvernek, szóval ezért szoktam erősen szkeptikus lenni menedzselt nyelveken írt szoftverek C/C++ re-implementációjában, mert vagy valami hiányozni fog a sebesség-feature-biztonság hármasból, vagy nem fog adni akkora előnyöket, ami először látszott, mert csodák nincsenek. De azért hajrá... :)