Is JRuby too big for older Android devices?

[Robin2]

When I try to run the Ruboto-IRB camera example on my HTC phone it crashes because there is not enough heap space. My HTC phone allows 20MB of heap space.

I've converted that program to run as an external script (a bit like SL4A) with my simple JRuby on Android and it still tends to crash. Things are better if I go back to JRuby 1.6.8, but not by much.

Is there any way to significantly reduce the amount of heap space that Ruboto uses?

If not, it looks like JRuby is just too much of a burden for my phone. That's a pity because a scripting system (similar to SL4A but with access to the Android API) looks like a good idea. It's something you can't do with Mirah.

[Scott Moyer]

A couple of thoughts:

1) Android changed the way it handles heap, so things are moving in the right direction. The legacy problem is with us because the change only impacts devices with 3.0 or higher.

2) I've been playing with the speed issue which is related to the heap issue. When I was working on getting Ruboto running on the WIMM One (a watch running Android 2.1), it had a 16Mb heap limit. I got Ruboto running by moving the stdlib out of the apk (i.e., unpacking it on first run). This prevented a huge time and heap process of creating an index into the apk for every file it contained (a task that JRuby does with any jar it wants to load files out of). Anyway, I'm thinking we want to make that switch for ruboto to reduce start up. We will get a win on the heap front at the same time. I'm still working out the details. 

[Robin2]

Most of stdlib seems to be .rb files that you include in your program with "require". Presumably they could all be included in a directory (in assets ?) if $LOAD_PATH is suitably set. Would that obviate the need for JRuby to make the index you mention? -  and more importanty, reduce the demands on heap space? It looks like a lot of the other stuff in stdlib is unnecessary, for example the stuff in the bin directory.

I'm not sure I want to spend £200 on a new phone just to solve the heap problem.

...R

[Scott Moyer]

On Thu, Feb 28, 2013 at 12:34 PM, Robin2 <robin...@gmail.com> wrote:

Most of stdlib seems to be .rb files that you include in your program with "require". Presumably they could all be included in a directory (in assets ?) if $LOAD_PATH is suitably set. Would that obviate the need for JRuby to make the index you mention? -  and more importanty, reduce the demands on heap space? It looks like a lot of the other stuff in stdlib is unnecessary, for example the stuff in the bin directory.

No, assets are just another location inside the apk. We need to stream files out of the apk and dump them in the file system. They just need to be in the apk in a format that JRuby will not index them (i.e., another jar or a zip).

We strip out the bin directory. We do need a way for people who what their own copy of the stdlib to talke only the stuff they need (e.g., take 1.9, but not 1.8...or just a few portions of stdlib).

 

I'm not sure I want to spend £200 on a new phone just to solve the heap problem.

Hopefully the solution I'm working on will save you money :) BTW, I think if you root, you can modify the default heap space.

[Robin2]

Thanks Scott, but I'm a little confused ...

I'm not sure if you are saying that JRuby will only index them if they are in a jar or zip; or if you are saying that it indexes all files anywhere in the apk? (Your text seems to imply that it WON'T index them if they are in the APK in a jar or zip)

I am thinking of putting the stdlib .rb files into assets but not in a jar or zip - I may try it later today.

By the way this is another example where I believe strongly there is an advantage for the Ruboto developers having a "standard" JRuby for Ruboto rather than trying to match several different varieties.

...R

[Scott Moyer]

An Android apk file is a jar file. The build process takes the files in the stdlib jar and unpacks them and then packs them into the new apk jar. The only way to get the stdlib files into the file system on the device is to have them in a separate archive inside the apk (and unpack them after install) or to do a separate pull (of the archive) from the net (and then unpack it).

[Robin2]

Thanks again, Scott,

Sorry but I can't say that my confusion has been dissipated.

In a previous post you said "They just need to be in the apk in a format that JRuby will not index them (i.e., another jar or a zip)." which seems to mean that JRuby won't index them if they are in "another jar or a zip". Since they are already in a jar I thought you meant to say "i.e. NOT another jar or a zip". Your most recent post seems to imply that JRuby will index anything that's anywhere in the APK.

And to add to my confusion if I omit the stdlib jar altogether (so it can't be indexing anything) it has no obvious effect on startup time. I measured it with a stopwatch and it may have fallen from 16 seconds to 15 seconds.

Another question. When you say "into the file system" do you mean "onto the sdcard"? Where else could they go (if not in the apk) in a non-rooted device.

Thanks again ...R

[Scott Moyer]

I'm definitely not saying that I completely understand the internals of JRuby. I uncovered the indexing issue when I was examining the heap used on the WIMM One. I am still working out whether JRuby automatically indexes jars inside of jars or not. It seems like JRuby will create its index the first time it attempts to access a jar (to look for a file in it). Right now we set the path to include the stdlib within the apk, so it gets indexed even if it is never used.

I don't think that moving the stdlib out of the apk will be a big enough win in itself. It will impact the heap, though, and that might be enough to justify it. I do think there may be a start-up speed win by not loading start-up files from the jar (jruby, java, kernal, etc.). JRuby is still indexing things even if the stdlib is not included. It turns out that there are a decent number of rb files for jruby itself. There are also a substantial number of files for joda (timezone information for the date class) and jcoding (character mappings for various languages).

When I talk about the file system, I'm talking about the internal storage (in the /data/data/<package_name>/files) directory. We could store things in the sdcard, but that would not be very secure.

--
You received this message because you are subscribed to the Google Groups "Ruboto (JRuby on Android)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruboto+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Robin2]

Thanks again Scott,

I guess as a result of your original helpful reply I got carried away and forgot the purpose of my original post which was to open up a discussion about whether it is just too much trouble to support Android OSs earlier than V3 - especially when you have very limited development resources.

I suspect none of the optimizations of JRuby would be necessary if you only worked with V3 and up.

...R

On Friday, March 1, 2013 7:59:18 PM UTC, Scott wrote:

I'm definitely not saying that I completely understand the internals of JRuby. I uncovered the indexing issue when I rb 
 

[Robin2]

PS ... I think I've just "saved" £100 by installing Android 4 for free on an old EEE pc 701

...R