[libbluray-devel] JRE for Android part 2

[Petri Hintukainen]

ke, 2021-01-27 kello 16:52 +0200, Shaya Potter kirjoitti:
> On Wed, Jan 27, 2021 at 4:46 PM Petri Hintukainen <
> phintuka at users.sourceforge.net> wrote:
> > 
> > Another thing that could be worth of trying is disabling JIT (I
> > don't
> > know if Android allows running user-generated code, or if JIT is
> > even
> > enabled in android build).
> > This can be done by executing the following line unconditionally:
> > 
> >     option[n++].optionString = str_dup("-Xint");
> > 
> > (= replace if(getenv("BDJ_JVM_DISABLE_JIT")) with if(1) )
> > 
> 
> I don't believe it uses the jit, I believe android use zerovm, which
> is total bytecode interpretation.  With that said, I'd guess that
> should be sufficient for bluray xlets from a perfomance perspective,
> as they were built to be run on very constrained devices?

Yes and no. HW players use native code for graphics, but in libbluray
all image manipulation is done at Java side (including things like
image scaling, rotating and alphablending).

When we tested PhoneME years ago, menus with heavy animations were
really slow without JIT. But PhoneME didn't work in 64-bit
environments, so nobody really cared. (if there was 64-bit support it
would have been perfect JVM for bluray).

Anyway, this is problem only with few discs. And moving most expensive
parts to native side wouldn't be too big task. There just was no reason
to do it with JIT available.

There are also reasons to not use JIT. Xlets are sometimes very old,
and always based on Java 1.4. JIT uses aggressive optimizations and
sometimes triggers Xlet issues/bugs that are invisible in interpreted
mode (ex. with memory synchronization). I think even Java memory model
was changed at some point after BD-J / Java ME 1.4...

> yep: http://openjdk.java.net/projects/mobile/android.html.  This is,
> I believe less because of not being able to have a jit on android
> (any web browser probabl jit's javascript) and more that it doesn't
> include any assembly, so its meat to be their most portable vm.