abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 20:22 | Nová verze

Před měsícem byla vydána Fedora 27 ve dvou edicích: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server byl "vzhledem k náročnosti přechodu na modularitu" vydán pouze v betaverzi. Finální verze byla naplánována na leden 2018. Plán byl zrušen. Fedora 27 Server byl vydán již dnes. Jedná se ale o "klasický" server. Modularita se odkládá.

Ladislav Hagara | Komentářů: 0
včera 10:22 | Zajímavý článek

Lukáš Růžička v článku Kuchařka naší Růži aneb vaříme rychlou polévku z Beameru na MojeFedora.cz ukazuje "jak si rychle vytvořit prezentaci v LaTeXu, aniž bychom se přitom pouštěli do jeho bezedných hlubin".

Ladislav Hagara | Komentářů: 12
včera 07:22 | Komunita

Od 26. do 29. října proběhla v Bochumi European Coreboot Conference 2017 (ECC'17). Na programu této konference vývojářů a uživatelů corebootu, tj. svobodné náhrady proprietárních BIOSů, byla řada zajímavých přednášek. Jejich videozáznamy jsou postupně uvolňovány na YouTube.

Ladislav Hagara | Komentářů: 0
11.12. 19:22 | Nová verze

Ondřej Filip, výkonný ředitel sdružení CZ.NIC, oznámil vydání verze 2.0.0 open source routovacího démona BIRD (Wikipedie). Přehled novinek v diskusním listu a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
11.12. 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 2
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 2
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 4
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
7.12. 11:11 | Komunita

Naprostá většina příjmů Mozilly pochází od výchozích webových vyhledávačů ve Firefoxu. Do konce listopadu 2014 měla Mozilla globální smlouvu se společností Google. Následně bylo místo jedné globální smlouvy uzavřeno několik smluv s konkrétními vyhledávači pro jednotlivé země. V USA byla podepsána pětiletá smlouva s vyhledávačem Yahoo. Dle příspěvku na blogu Mozilly podala společnost Yahoo na Mozillu žalobu ohledně porušení této

… více »
Ladislav Hagara | Komentářů: 0
7.12. 05:55 | Zajímavý článek

V Londýně probíhá konference věnovaná počítačové bezpečnosti Black Hat Europe 2017. Průběžně jsou zveřejňovány prezentace. Videozáznamy budou na YouTube zveřejněny o několik měsíců. Zveřejněna byla například prezentace (pdf) k přednášce "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". Dle oznámení na Twitteru, aktualizace vydaná společností Intel nevylučuje možnost útoku.

Ladislav Hagara | Komentářů: 5
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 963 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Java Native Interface: vytváříme virtuální stroj

    10. 8. 2011 | Luboš Doležel | Programování | 4039×

    Odskočíme od „nudných“ témat a vytvoříme si svůj vlastní javovský virtuální stroj. Také si ukážeme, jak se dá v systému najít instalace Javy.

    Obsah

    Toto je téma, které můžete přeskočit, pokud vaším jediným důvodem, proč se o JNI zajímáte, je rozšiřování javovských aplikací o nativní kód. V tomto případě žádné JVM nevytváříte, protože to je vytvořeno při spuštění javovské aplikace.

    Javo, kde jsi?

    link

    Pokud se ale snažíte o obrácený postup, tedy z nativní aplikace v C/C++ spouštět Javu, hned se musíte starat o něco navíc. Prvním krokem pro vytvoření JVM je najít knihovnu, která se na Linuxu nazývá libjvm.so. Problémem je, kde takovou knihovnu vlastně hledat. Typicky, pokud jsem tuto otázku někomu položil, dostal jsem odpověď: „No přece v /xyz/abc, kde jinde?“ Je pravda, že /usr/lib/jvm je už docela sjednocené umístění pro instalace JRE/JDK, nebo alespoň symbolické odkazy na ně (třeba kamsi do /opt).

    Horší je, že pokud se chceme vydat touto cestou, musíme také zvolit to správné JRE, protože co jsem se díval, tak na každém mém systému jsou alespoň dvě JRE. Což znamená heuristiku, nebo si napsat něco, co přečte distribučně specifické konfigurační soubory. Pokud by vás napadlo nějak zkoumat /usr/bin/java, tak vězte, že zatímco na Debianu se přes sérii symbolických odkazů dostanete k binárce v té správné instalaci JRE, např. na Gentoo skončíte u skriptu run-java-tool.

    Populární cestou je mít v aplikaci napevno spoustu cest, kde by Java mohla být. Takto to řeší například skript FindJNI.cmake v CMake:

      /usr/lib
      /usr/local/lib
      /usr/lib/jvm/java/lib
      /usr/lib/java/jre/lib/{libarch}
      /usr/lib/jvm/jre/lib/{libarch}
      /usr/local/lib/java/jre/lib/{libarch}
      /usr/local/share/java/jre/lib/{libarch}
      /usr/lib/j2sdk1.4-sun/jre/lib/{libarch}
      /usr/lib/j2sdk1.5-sun/jre/lib/{libarch}
      /opt/sun-jdk-1.5.0.04/jre/lib/{libarch}
      /usr/lib/jvm/java-6-sun/jre/lib/{libarch}
      /usr/lib/jvm/java-1.5.0-sun/jre/lib/{libarch}
      /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/{libarch}       # can this one be removed according to #8821 ? Alex
      /usr/lib/jvm/java-6-openjdk/jre/lib/{libarch}
      /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/{libarch}        # fedora
      # Debian specific paths for default JVM
      /usr/lib/jvm/default-java/jre/lib/{libarch}
      /usr/lib/jvm/default-java/jre/lib
      /usr/lib/jvm/default-java/lib
    

    Osobně se mi žádný z těchto způsobů nelíbil, a tak jsem zvolil to nejjednodušší. Co funguje na všech distribucích? Příkaz java. Před načtením libjvm.so proto spouštím následující primitivní třídu v podprocesu:

    public class GetJavaHome {
    	public static void main(String[] args) {
    		System.out.println(System.getProperties().getProperty("java.home", null));
    	}
    }
    

    Výstup této třídy nám prozradí místo, kde je aktuálně používaná Java nainstalována. Správnou cestou pro nalezení libjvm.so by nyní bylo zavolat uname(), převést si utsname.machine na název architektury dle zvyklostí Javy (například x86-64 → amd64) a v tomto podadresáři už najít kýženou knihovnu, třeba ještě někde pod adresářem server (serverové VM). Osobně jsem v tomto trochu lenoch a knihovnu spíš hledám pomocí find, protože i kdyby tam bylo VM víc, tak mi vcelku nesejde na tom, které se použije. Samozřejmě, pokud je nastavena hodnota prostředí pojmenovaná JAVA_HOME, můžeme hledat právě tam.

    Vytváříme JVM

    link

    Máme-li knihovnu, můžeme to konečně rozjet.

    #include <dlfcn.h>
    
    typedef jint (*cjvm_fn) (JavaVM **pvm, void **penv, void *args);
    
    int main(int argc, char** argv)
    {
    	void* lib = dlopen(argv[1], RTLD_LAZY);
    	cjvm_fn createfn = (cjvm_fn) dlsym(lib, "JNI_CreateJavaVM");
    
    	// ...
    }
    

    JNI_CreateJavaVM je jednou z mála funkcí, které takto knihovna exportuje. Této funkci předáme parametry pro VM a zpátky dostaneme nám známý JNIEnv* a navíc i JavaVM*. Parametry pro JVM mohou být v podobě standardních javovských -Dklíč=hodnota nebo specifických pro JNI (například -verbose:jni). Specialitou navrch je možnost nastavit si háčky na volání vprintf, exit a abort.

    JavaVMInitArgs vm_args;
    JavaVMOption options[1];
    JNIEnv* env;
    JavaVM* vm;
    
    options[0].optionString = "-Djava.class.path=lib/lib1.jar:lib/lib2.jar";
    
    vm_args.version = JNI_VERSION_1_2;
    vm_args.ignoreUnrecognized = true;
    vm_args.options = options;
    vm_args.nOptions = sizeof(options) / sizeof(options[0]);
    
    if (createfn(&vm, (void **)&env, &vm_args) < 0)
      // ....
    
    // Teď už můžeme přes JNIEnv pracovat
    

    Stojí za zmínku, že používání wildcards (*) v java.class.path mi u JNI nikdy nefungovalo. Ukončení práce s VM:

    vm->DestroyJavaVM();
    

    A ještě jedno upozornění: JVM si na sebe přemapuje handlery signálů jako SIGSEGV nebo SIGABRT a následně automaticky generuje logy s výpisem zásobníku a dalšími informacemi.

    Práce s vlákny

    link

    Pokud bylo vlákno vytvořeno z Javy, nemusíme řešit vůbec nic. JVM si všechny nezbytné struktury spravuje pochopitelně samo. Jenže v případě, že v našem nativním programu vytvoříme vlákno my, musíme o jeho životě dát JVM vědět (pokud v něm budeme pracovat s Javou). Zde používáme funkce AttachCurrentThread a DetachCurrentThread.

    JavaVM* g_vm;
    
    void* vlakno(void*);
    
    int main()
    {
        // ...
        pthread_t tid;
        pthread_create(&tid, 0, vlakno, 0);
    }
    
    void* vlakno(void*)
    {
        JNIEnv* env;
        g_vm->AttachCurrentThread(&env, 0);
    
        // můžeme pracovat s env
    
        g_vm->DetachCurrentThread();
    }
    

    Když z nějakého důvodu nezavoláme DetachCurrentThread(), DestroyJavaVM() bude na toto volání čekat. Takže pokud jsme vlákno ukončili bez tohoto volání, aplikace bude zablokovaná navždy. U složitějších aplikací, které používají vlákna aktivně, si můžeme práci usnadnit třeba takto:

    JavaVM* g_vm;
    __thread JNIEnv* t_env = 0; // Thread Local Storage
    
    JNIEnv* getEnv()
    {
        if (!t_env)
            g_vm->AttachCurrentThread(&t_env, 0);
        return t_env;
    }
    

    A DetachCurrentThread vyřešit pomocí páru pthread_cleanup_push() a pthread_cleanup_pop() (i když to nemusí být vždy spolehlivé). Ještě jedna věc stojí za zmínku: jestliže vytváříme vícero virtuálních strojů, vlákno by mělo patřit jen jednomu z nich.

    Registrace nativních funkcí

    link

    Rozšiřujeme-li javovskou aplikaci o nativní metody, nemusíme registraci provádět ručně – stačí se držet „předepsaných“ jmen C funkcí a Java si je najde sama. Jakmile rozšiřujeme nativní aplikaci o Javu, funkce k metodám je nutné zaregistrovat ručně (i když -export-dynamic by možná zabral, nezkoušel jsem). Tuto registraci můžeme provádět kdykoliv v průběhu života JVM.

    Funkce lze registrovat hromadně. Jednoduchá ukázka:

    JNINativeMethod m[2];
    jclass cls = t_env->FindClass("test/NaseTrida");
    
    m[0].name = "test1";
    m[0].signature = "()V";
    m[0].fnPtr = nativni_test1;
    
    m[1].name = "test2";
    m[1].signature = "(Ljava/lang/String;)I";
    m[1].fnPtr = nativni_test2;
    
    t_env->RegisterNatives(cls, m, sizeof(m) / sizeof(m[0]));
    

    Tato ukázka by zaregistrovala metody z třídy jako je tato:

    package test;
    
    public class NaseTrida {
        public native void test1();
        public native int test2(String str);
    }
    

    Registrace neexistující metody vyvolá javovskou výjimku, takže si ji hlavně nezapomeňte vyzvednout, pokud RegisterNatives vrátí záporné číslo. Existuje i funkce UnregisterNatives, avšak ta běžně nenachází využití.

    Použití metody označené klíčovým slovem native z javovského kódu v době, kdy není žádná nativní funkce zaregistrována nebo se ji nepodařilo najít, vyvolá samozřejmě taktéž výjimku.

    Uvolňování paměti v nativním kódu

    link

    Aneb nacházíme konečně důvod, proč existuje metoda finalize() – tím je uklizení prostředků alokovaných v nativním kódu. Nejčastěji se odsud volá close() pro zavírání souborů, tak to Javisti jistě znají. Na toto nesmíme zapomenout ani u vlastních tříd, avšak samotné dispose() by nemělo být nativní metodou. Správné řešení může vypadat takto:

    public class Trida {
        protected void finalize() {
            disposeNative();
        }
        protected native void disposeNative();
    }
    

    Mapování tříd na nativní objekty

    link

    Zde jen v krátkosti zmíním jednu věc, kterou jsem viděl v kódu psaném inženýry z Google (konkrétně to byl javovský wrapper pro knihovnu Tesseract). Pokud si naše nativní funkce ukládají vlastní data, tak si musíme vytvořit nějaké mapování mezi javovským objektem a těmito daty.

    To, co vám teď ukáži, je ale prostě špatně. Jednak to nebude fungovat na x86-64 a i kdyby se tam dal long, tak je to principiálně nekorektní (ačkoliv uznávám, že je to jednoduché na napsání).

    public class Trida {
         private int nativniData; // v nativniData je nějaký Cčkový ukazatel
    }
    

    Nejsnazší řešení by mohlo vypadat jako mapa mezi Cčkovým ukazatelem a javovským objektem. První problém je v tom, že toto řešení bude leakovat reference. Druhým problémem je lineární složitost hledání v takové mapě, protože binárním půlením to nejde: reference na javovské objekty je nutné porovnávat pomocí volání IsSameObject, proto by se muselo iterovat přes všechny prvky.

    Lepší je proto spíš do javovské třídy dát nějaký jedinečný identifikátor, který pak půjde mapovat na Cčkový ukazatel. Prvek takové mapy můžeme vymazat po vyvolání finalize().

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    12.8.2011 10:32 Tomáš
    Rozbalit Rozbalit vše Re: Java Native Interface: vytváříme virtuální stroj

    Zajímalo by mě proč je kontrukce

    public class Trida {
         private long nativniData; // v nativniData je nějaký Cčkový ukazatel
    }
    

    špatně. V rámci metody disposeNative() se pak nativniData korektně uvolní z paměti.

    Stejně tak nerozumím tomu, proč by metoda finalize neměla být nativní? S předpokladem, že nativní finalize volá finalize předka ve svém závěru.

    Předem díky za vysvětlení.

    Luboš Doležel (Doli) avatar 13.8.2011 16:05 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Java Native Interface: vytváříme virtuální stroj
    V rámci metody disposeNative() se pak nativniData korektně uvolní z paměti.
    Jde o principiání nekorektnost. Ukazatale jsou a vždy budou jen 64bitové, že tam dáváte long?

    To kolem finalize bych považoval za best practice. Jde spíš o praktičnost. Pokud by bylo finalize nativní a vy byste potřeboval najednou uzavírat nějaký soubor, tak byste to musel udělat přidáním volání close() do nativního kódu (což je zbytečně složité). Tak je lepší si to rovnou oddělit.
    16.8.2011 14:02 Tomáš
    Rozbalit Rozbalit vše Re: Java Native Interface: vytváříme virtuální stroj

    Už rozumím. Jde o to, že není nikde definováno, že sizeof(void*) < sizeof(long). Já bych se asi místo vytváření mapy (= výkonostní zabiják) spíše přikláněl,k využití nativní třídy CPointer, která má pointer peer deklarovaný jako

    public abstract class CPointer {
    protected long peer;
         ...
    }
    

    A kruci, zase long. ;-)

    Luboš Doležel (Doli) avatar 17.8.2011 02:23 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Java Native Interface: vytváříme virtuální stroj
    Mapa není až takový zabiják :-) Hledání ve vhodně udělané mapě je v čase log_2(n). Při 10 tisísích takto spravovaných objektů je pro dohledání ukazatele nutné projít jen cca 13 prvků z mapy, než je nalezen ten správný. To není vůbec zlé.

    Jinak ty odkazované stuby jsou taková znouzecnost, neboli jak emulovat C v Javě. (Normálně by se na tohle použilo JNA a člověk by si tyhle věci psát nemusel.) Je možné, že ukazatel nebude nikdy delší než javovský long. Ale takových předpokladů se už ve světě počítačů udělalo tolik a kolik škody to taky napáchalo... Mapa mě hřeje na srdci víc :-)
    15.12.2013 19:20 korem
    Rozbalit Rozbalit vše Re: Java Native Interface: vytváříme virtuální stroj
    O vytváření vlastních virtuálek jsem se ani doposud nezajímal, ale tenhle tvůj článek mi docela rozšířil obzory. Jinak Java mi přijde jako jeden z nejlepších jazyků, nejen srozumitelně, ale i v rámci nějakýho uplatnění. A nejlépe uplatnění v cizině. Zkoušel jsem najít nějaké weby, které se tím specializují, nevíte nějaké osvědčené? Mě říkal kámoš o itprace-nemecko.cz/,prý mu tam sehnali nějakou práci, akorát jsem se ještě nedostal k tomu, abych tam napsal životopis... :D (snad neva ten odkaz, nemyslel jsem to jako spam, spíš jestli s touhle konkrétní firmou má někdo nějaké zkušenosti)

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.