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. -- Chris Gray /k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/ chris.g...@kiffer.be +32 3 216 0369 Come and see us at Embedded World 2009 in Nürnberg, 3-5.3.2009: Hall 12, Stand 560 (DSP Valley). http://www.embedded-world.de/ _______________________________________________ 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
