<div dir="ltr">Ok I'm doing the stupid way of doing things because other way every time I touch the code it fails.<div><br></div><div>can you tell me why it's <b>only</b> loading the first entry?<div><br></div><div>static const char all_libs[] = {"libawt",<br> "libawt_headless",<br> "libawt_xawt",<br> "libdt_socket",<br> "libfontmanager",<br> "libhprof",<br> "libinstrument",<br> "libj2gss",<br> "libj2pcsc",<br> "libj2pkcs11",<br> "libjaas_unix",<br> "libjava",<br> "libjava_crw_demo",<br> "libjawt",<br> "libjdwp",<br> "libjli",<br> "libjpeg",<br> "libjsdt",<br> "libjsig",<br> "libjsound",<br> "liblcms",<br> "libmanagement",<br> "libmlib_image",<br> "libnet",<br> "libnio",<br> "libnpt",<br> "libsctp",<br> "libsunec",<br> "libtinyiconv",<br> "libunpack",<br> "libverify",<br> "ibzip",};<br> <br><br> dl_dlopen(all_libs, NULL);<br><br><br> result = JNI_CreateJavaVM_fp(jvm, (void**) env, &args);<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 27, 2021 at 7:33 PM Petri Hintukainen <<a href="mailto:phintuka@users.sourceforge.net">phintuka@users.sourceforge.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">ke, 2021-01-27 kello 16:52 +0200, Shaya Potter kirjoitti:<br>
> On Wed, Jan 27, 2021 at 4:46 PM Petri Hintukainen <<br>
> <a href="mailto:phintuka@users.sourceforge.net" target="_blank">phintuka@users.sourceforge.net</a>> wrote:<br>
> > <br>
> > Another thing that could be worth of trying is disabling JIT (I<br>
> > don't<br>
> > know if Android allows running user-generated code, or if JIT is<br>
> > even<br>
> > enabled in android build).<br>
> > This can be done by executing the following line unconditionally:<br>
> > <br>
> > option[n++].optionString = str_dup("-Xint");<br>
> > <br>
> > (= replace if(getenv("BDJ_JVM_DISABLE_JIT")) with if(1) )<br>
> > <br>
> <br>
> I don't believe it uses the jit, I believe android use zerovm, which<br>
> is total bytecode interpretation. With that said, I'd guess that<br>
> should be sufficient for bluray xlets from a perfomance perspective,<br>
> as they were built to be run on very constrained devices?<br>
<br>
Yes and no. HW players use native code for graphics, but in libbluray<br>
all image manipulation is done at Java side (including things like<br>
image scaling, rotating and alphablending).<br>
<br>
When we tested PhoneME years ago, menus with heavy animations were<br>
really slow without JIT. But PhoneME didn't work in 64-bit<br>
environments, so nobody really cared. (if there was 64-bit support it<br>
would have been perfect JVM for bluray).<br>
<br>
Anyway, this is problem only with few discs. And moving most expensive<br>
parts to native side wouldn't be too big task. There just was no reason<br>
to do it with JIT available.<br>
<br>
There are also reasons to not use JIT. Xlets are sometimes very old,<br>
and always based on Java 1.4. JIT uses aggressive optimizations and<br>
sometimes triggers Xlet issues/bugs that are invisible in interpreted<br>
mode (ex. with memory synchronization). I think even Java memory model<br>
was changed at some point after BD-J / Java ME 1.4...<br>
<br>
> yep: <a href="http://openjdk.java.net/projects/mobile/android.html" rel="noreferrer" target="_blank">http://openjdk.java.net/projects/mobile/android.html</a>. This is,<br>
> I believe less because of not being able to have a jit on android<br>
> (any web browser probabl jit's javascript) and more that it doesn't<br>
> include any assembly, so its meat to be their most portable vm.<br>
<br>
<br>
_______________________________________________<br>
libbluray-devel mailing list<br>
<a href="mailto:libbluray-devel@videolan.org" target="_blank">libbluray-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/libbluray-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/libbluray-devel</a><br>
</blockquote></div>