Hi Todd,
> I have a long running PilBox Android app that tends to just "crash" (with a
> "Webpage not Available... net:ERR_CONNECTION_REFUSED") after running for a few
> hours. At this point, the REPL is unresponsive at this point and nothing is in
> the PilBox log file.
I need PilBox open all day for various reasons, and monitor it constantly. So I
notice quickly if something goes wrong. In fact it crashes sometimes, but it is
usually longer than a few hours (more like about once or twice a week).
Typical crashes are usually not PilBox's fault. Android is a nasty host system,
it kills apps whenever it feels it needs memory (kills with -9, not -15 !!!).
Other situations are when Android updates system components in the background
(most notably the System WebView), then PilBox is also killed.
But: In most of the above cases, there is no connection error, but PilBox
"resets", i.e. it goes to the home screen and lost its context. Technically,
this means a new instance of the internal PicoLisp process was started.
If you see the above connection errors, it seems that the PicoLisp process
is gone and not restarted. Not sure.
Also you probably know that you can force a full stop of PilBox and PicoLisp by
swiping it off. This stopping did not work reliable in older PilBoxes and was
improved a few months ago.
BTW, do you use a current version of PilBox?
Latest official release was 23.7.13 (183)
> My app makes heavy use of Java calls (dozens every 5 seconds) and this got me
> wondering about how PilBox treats the Java object life-cycle.
A valid question.
> I don't see clearly how the Java objects themselves are referenced so as not
> to
> be collected by the Java GC. I do see a static HashMap in InOut.java. Are Java
> objects "put" there to save them from the GC?
Yes, this is exactly the reason.
> If so, when are they removed from the HashMap? I don't see any "remove" in
> InOut.java or other PilBox Java sources.
>
> If objects are referenced there Is it possible that these objects are never
> freed?
> ... 2nd mail
> I should be a little clearer: I "instantiate" dozens Java object every 5
> seconds
> and wonder how Pilbox affects their life-cycle....
I understand the question well. And was aware of the trade offs from early on.
The objects in the hash map are indeed never removed. This would be difficult to
implement, because the Java side has no information about which objects are
still in use on the Lisp side.
Is this is really the cause of the problem? Most java calls do not make a new
object each time, and stored in the hash map are not all involved objects, but
only those which are reflected back to Lisp (and not all created internally).
And: The objects in the hash map are truly minimal. They have no local data,
they are just stubs. They seem big when looked at with (show Obj), but all these
data are generated on the fly via reflection and not part of the objects
themselves.
Still, you are right that this mechanism will use more and more memory.
Have you checked it? I did occasionally, using something like this code in the
REPL:
(let R (java "java.lang.Runtime" 'getRuntime)
(java R 'gc)
(let
(Fmt (-7 9)
Mem (java R 'totalMemory)
Free (java R 'freeMemory) )
(tab Fmt "Total" (format Mem 3 "." ","))
(tab Fmt "Free" (format Free 3 "." ","))
(tab Fmt "Used" (format (- Mem Free) 3 "." ",")) )
R )
Perhaps we can come up with ideas how to improve the situation.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
