Hi Bram van der Steen , When using the current 32-bit based architecture, we can expect to encounter rare inherent limitations that can only be worked around to a certain extent. We are currently working on transitioning to a 64-bit architecture (no concrete ETA yet but we'll give updates when we get closer to it), which should help mitigate these issues significantly.

In the meantime, one potential solution we recommend is looking at adopting our cloud services. Our cloud-based platform has been built for scale, so the expectation would be to alleviate many of these memory-related challenges and improve the overall experience with jobs and TMs of any size (we do have certain limits in place in the cloud based platform also, but those are more meant to protect the platform than anything you would encounter in automation).

It would also be great if you could provide the exact stack traces of the OutOfMemoryExceptions you are encountering. Analyzing these traces will help us understand their frequency and any additional context. It would also be beneficial to have access to the larger TMs you are using plus the test files and languages used, so we can try and reproduce these issues. If you've shared these previously, please let us know, as we could also use them for testing with our upcoming 64-bit architecture.

Additionally, until we gain more insights, it might also be intereting to explore memory management options on your end, such as freeing up memory between jobs, starting from fresh. This approach should help enhance memory efficiency.

Hi Bram van der Steen , When using the current 32-bit based architecture, we can expect to encounter rare inherent limitations that can only be worked around to a certain extent. We are currently working on transitioning to a 64-bit architecture (no concrete ETA yet but we'll give updates when we get closer to it), which should help mitigate these issues significantly.

In the meantime, one potential solution we recommend is looking at adopting our cloud services. Our cloud-based platform has been built for scale, so the expectation would be to alleviate many of these memory-related challenges and improve the overall experience with jobs and TMs of any size (we do have certain limits in place in the cloud based platform also, but those are more meant to protect the platform than anything you would encounter in automation).

It would also be great if you could provide the exact stack traces of the OutOfMemoryExceptions you are encountering. Analyzing these traces will help us understand their frequency and any additional context. It would also be beneficial to have access to the larger TMs you are using plus the test files and languages used, so we can try and reproduce these issues. If you've shared these previously, please let us know, as we could also use them for testing with our upcoming 64-bit architecture.

Additionally, until we gain more insights, it might also be intereting to explore memory management options on your end, such as freeing up memory between jobs, starting from fresh. This approach should help enhance memory efficiency.