> And if you want to enable 3rd parties to develop applications for
> your device you would IMO be pretty crazy to do it in native
> code. It's considerations like that which are driving the adoption
> of Java in consumer electronics.
We got pretty insane learning every bug and limitation and quirk of every device and every library
or toolchain we had to work with. Frustrating enough to even contemplate vertical integration.
Yet, we're aware of the dangers of being locked in to specific vendors. Altogether crazy.
Regards
Jonathan
Chris Gray wrote:
On Tuesday 03 February 2009 12:32:48 Jamie Lokier wrote:
Chris Gray wrote:
On Monday 02 February 2009 22:01:12 Jamie Lokier wrote:
I didn't use Java because I thought it wouldn't fit, to be honest.
There's about 10MB free on my 64MB device (32 allocated to video
coprocessors, away from Linux; the rest is used by Linux, utils etc.)
I found that's actually not enough when streaming from hard disk -
because Linux's page allocator can't handle it, playback struggles.
So I thought adding Java would make it worse.
It probably would have: you can certainly run Java applications in less
than 10 MB (or even 5 MB), but you need to keep them pretty simple (and
when the memory consumption starts to grow it can be hard to put your
finger on just why). OTOH I know people who are doing pretty complex
stuff (including genetic algorithms, would you believe) in something like
18 MB.
That's good to know. My customer wants to use Java, I can use this to
say "no, bad idea!" :-)
Hm, and I'm supposed to be an advocate of embedded Java. :-/ But honestly if
memory is as tight as this it would probably better not to go that route.
Even if it fits in 5MB, the trouble is the system needs 10MB _free_ to
stream from hard disk reliably. Linux 2.4 with the "page_alloc2"
fragmentation-avoidance allocator cannot release page-cache due to
streaming I/O smoothly, and with "page_alloc" (the normal Linux
allocator), it's smooth but quickly fragments so much that launching
new apps, such as shell scripts or telnet shells stops working.
There are some aspects of Java which make it hard to keep the
memory consumption real down low - the reflection data for example
(all those strings!) and the frustrating lack of modularity in the
class libraries. Yes you can compile stuff AOT and strip out unused
methods and reflection data - but be careful because the Java
libraries themselves use reflection quite a lot. The good news is
that once you have a certain critical mass of commonly- used core
classes from java.lang, java.io, java.net and java.util loaded the
memory consumed by class libraries starts to stabilise a bit -
provided of course that you don't start dragging in every cute
open-source library you see on the web.
And of course, no MMU means no swapping in just those parts of the
libraries which are used, so you really need enough RAM.
Quite. Of course Java does bring some advantages too - managed code means that
you shouldn't need to worry about applications writing to other applications'
(or system) memory. You need to trust the JVM, but that has probably been
scrutinised by more eyeballs than your own applications. And if you want to
enable 3rd parties to develop applications for your device you would IMO be
pretty crazy to do it in native code. It's considerations like that which are
driving the adoption of Java in consumer electronics.
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
