tedapt wrote:
> Thanks Breton. There is a lot of mystery in the Java garbage collection
> aspect of this problem. However, this is a large app and about two years in
> development, conversion to C is unfortunately not an option. What I really
> need is a better way to measure where the memory problem arises (or perhaps
> that is just a shadow of the real problem).
>
Sorry - I realize that wasn't a particularly helpful suggestion. :)
The best definition for "Buffers" that I've found so far is:
http://lwn.net/Articles/28345/ - which look like raw disk buffers;
presumably for speeding up device i/o, beyond what a standard disk cache
is capable of doing.
Are you using the sdcard for disk storage on this device? If so, can
you try running your application completely off of a ramdisk or off of
an NFS partition and verify that the problem still occurs.
> I suppose at this point I'm really looking for more insight into what
> "Buffers" really means? I've read that this is either related to data blocks
> or interprocess communications. Hoping to better understand what that means
> (and ideally to somehow connect that to a particular thread) to perhaps nail
> down the few lines of Java code somewhere in the vast sea that could be
> causing the problem and rewrite that.
>
I don't think its a few java lines that are causing the problem. If the
machine is locking up then you've uncovered a kernel bug; which isn't
unlikely given the amount of dodgey code used to get memory working on
the ep93xx with linux - due to the ep93xx's awkward layout of physical
memory.
> Otherwise, hoping to identify some OS configuration variables (e.g., through
> sysctl) that might make a difference if tweaked.
>
> Have also tried allocating more and less heap to Java, with no effect, as
> well have tried touching large chunks of memory when my app initializes to
> try to ensure that enough memory is being allocated. But once again, the
> problem seems most closely tied to the "Buffers" value, not overall memory
> allocation.
>
Can you try running your application under a 2.6 series kernel? Either
try with TS's 2.6.21, or try with some of the later revisions, like
2.6.27. I don't believe that 2.6.28 or 2.6.29 are stable yet using
sparsemem.
Finally, are you doing I/O by peek/poke via /dev/mem?
Cheers,
-Brett
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|