I'm compiling literally hundreds or thousands of IDL files. Some are small. Some are complex. Refactoring my IDLs into bigger, monolithic IDLs is out of scope for this question and consider it not an option due to other reasons.
Due to the count, I'd really like to use the rtiddsgen_server so I can avoid the overhead of spawning a JVM each time.
The problem is that the rtiddsgen server doesn't seem to have any memory management. It doesn't seem to flush any memory after processing an IDL. Therefore, the JVM size grows to an enormous size. On windows it's hitting 2GB memory and never seems to return any of it. On some linux boxes, it comes to a crawl.
Is my only option to tame it with the max JVM heap size? Can somebody @ RTI tell me if it is smarter than It think it is, as far as managing memory as a server when getting called hundreds or thousands of times?
I'm using 5.2.3 and running on Oracle Java 1.8
Thanks,
-Ryan
Hi Ryan,
Sorry for the late response.
Is that memmory usage something that you have only observerd with the rtiddsgen_server, or does it also happens if you run rtiddsgen (without the server)?
Rtiddsgen_server shouldn't be keeping state information from previous IDL runs. Does it rearch the 2GB right away or is it something that it is reachead after some time running?
We are going to do some test on our side to see if we observe the same situation and we'll let you know.
Best regards,
Aida
Aida,
When using rtiddsgen_server on Windows the memory growth happens right away. When using rtiddsgen without server the memory does not grow and stays fairly level throughout the run. On Fedora24 the memory growth stays level and does not grow much when using both rtiddsgen_server and rtiddsgen. However, on Fedora24, rtiddsgen_server runs MUCH slower than rtiddsgen. When I use server, I can generate source files for about 100 IDL files in an hour. When I use rtiddsgen, I can generate source files for close to 3,000 IDL files in an hour. I use the same IDL files for both runs so there isn't an issue with the complexities of the files being different.
-Alex