I've got a working version that avoids running out of memory at 10 threads/second, but if the rate is 100 instead of 10, thread creation still outruns the gc and we run out of memory.
I suspect the culprit here is the over-simple, arbitrary 30 second pause in the system process. This ought to be modified somehow; My thought is that this delay ought to be interrupted if the heap reaches some target of memory full. For some reason, it takes 2 complete GC cycles for thread memory to actually be reclaimed, so for example when the first GC-mark phase is triggered, 300 processes are slated for deletion, when the second gc mark phase is triggered, they are all still there, so the pending count is 600, then the first 600 are actually finalized and the pending deletion count stabilizes at 600. Another oddity I noticed is that GC-mark frequently waits for 10-30 seconds for for process 3, which seems to be the EDT process. Finally, no matter how slowly processes are created, the IOS simulator returns an error 35 "too many threads" at around 5000. It's unclear what the problem may be. Perhaps its only a limit in the simulator. -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/codenameone-discussions. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/9f9f4ddd-c25e-4077-a618-5b3b4e4dd2f2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
