Description of core.memory.threads.* properties


I understand that the number of threads available for my application can be set via the core.memory.threads.size property. However, I don’t understand the relation with the other core.memory.threads properties:

In my .properties file I have the following properties defined:

  • core.memory.thread.block.size
  • core.memory.thread.max.nb.monitors
  • core.memory.thread.max.size
  • core.memory.threads.memory
  • core.memory.threads.pool.memory
  • core.memory.threads.pool.size

Where can I find a description of those and how to tune them? I couldn’t find any in the Device Developer’s Guide nor in the Standalone Application Developer’s Guide.

Also, do those properties have an impact on the simulator or is it restricted to the board?



These options are described in the Device Developer’s Guide available at (section Group: Threads).

Unfortunately the option property name is not displayed. This will be fixed in a future release.

However, one way to get the option property name is to open a MicroEJ Launch Configuration and move the mouse pointer over an option value. A tooltip appears with the option property name:

From the Device Developer Guide and a MicroEJ Launch Configuration, I manually updated options properties names:

The option core.memory.thread.max.nb.monitors is a Core Engine specific option available under Device > Core Engine category. It allows to specify the maximum number of monitors that can be owned by a Thread at the same time:

The two last options core.memory.threads.memory and core.memory.threads.pool.memory are deprecated options. They must be let as-is to their default value:


Hi Frederic, thanks for the answer.

Can you tell me if my understanding of pool.size, block.size and max.size is correct?

  • there is a pool which contains pool.size blocks of size block.size
  • when a thread requires some space of its stack, it fetch a block in the pool
  • max.size is the maximum number of block a thread can own
  • so the maximum stack size for a a thread is block.size * max.size
  • if a thread exceeds this maximum stack size, a StackOverflow occurs
  • if there are several threads requesting many blocks, we can also run out of block and, even though the thread owns less blocks than max.size, a StackOverflow can occur

So we have to find a balance between the maximum stack size for each thread and between the various threads running at the same time.
Am I correct?

Yes. As described above, the blocks size unit is in bytes.

Yes. A block remains attached to the thread until it is terminated (even if the stack decrease later during the thread execution). Here is the description from the Device Developer Guide:



Yes. The StackOverflowError reason is available in the error message. Here are the EDC specific error codes from the the Device Developer Guide:

1 Like