100 threads then robot code gets terminated

[shuhao]

.. again, the 100 threads are NOT concurrent. It is spawned during the life time of the operation ...

[Greg McKaskle]

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

[Chiller]

Originally Posted by shuhao

.. again, the 100 threads are NOT concurrent. It is spawned during the life time of the operation ...

Then kill the old threads!