Thread: 100 threads then robot code gets terminated
View Single Post
  #2   Spotlight this post!  
Unread 17-02-2012, 08:41
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
  
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,748
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: 100 threads then robot code gets terminated
I'm not that familiar with the Java VM implementation, but I assume it is stack based, like C and C++. Each thread is given its own stack along with other allocations for managing the thread resources. On some OSes that is not too big initially, but they have lots of VM room to grow into. On other OSes, they preallocate lots of stack for each thread. If your stack was 1MByte, then you would run the VM out of memory way before 100.

LabVIEW works around this by having a thread pool and generating its code to not be stack based, but be frame based. That allows it to have hundreds of parallel tasks without having hundreds of threads. But if your OS can handle hundreds of threads, you change a config and tell it to use that many. By default, it has four per processor per priority which are allocated as priorities are added.

On the DS, flip to the new Charts page and run your program. On the far right side are three numbers for free disk, RAM, and largest RAM. If the RAM is constantly dropping, you are hoarding or leaking memory. If the crash takes place about the time your RAM gets low, and especially when the Largest Block gets too small, then that explains it, right?

Greg McKaskle
Reply With Quote