SikuliX

Meet OutOfMemoryError with JAVA again --- cause ScreenHighlighter._opened

Asked by Bob

I have asked this question before(You can check under url https://answers.launchpad.net/sikuli/+question/204098) and RailMan has kindly given us a suggestion. I have tried according to his brief and also tried to call system.gc after every test cases. But it seems that it will still occur the error when we try to run many test cases at the same time. I tried to use JProfile to find out the reason, and I found that the int[] objects took out 256M memory. I think this is because that sikuli need convert the images to int[] to compare them. I wondered whether the sikuli framework release the resource after the comparision work. Thank you very much for your help.

Question information

Language:
English Edit question
Status:
Solved
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Solved by:
RaiMan
Solved:
Last query:
Last reply:
Revision history for this message
Best RaiMan (raimund-hocke) said : 		#1

Yes, the internally used resources are definitely freed (besides the fact, that every region stores the last captured screen image - which might get a (little) problem when using many large regions (e.g. a screen image of a screen 1920x1200 takes nearly 10MB storage).

So in your case, the problem are the intermediate copies/transformations of large images (the int[] are always captured images of the respective search area created with every find operation) in preparation of the native image match.

So depending on how many of these operations are in parallel, there might well be situations, where the sum of last_images stored with regions/screens and intermediate storage needs might get more than 256MB

So if you use regions to minimize the search area (I hope you do ! because this generally boosts performance and robustness), then it might be worth a try, to set at least the larger ones to null after they are not needed any longer.

Same goes for the screen objects (when used as search regions e.g. scr.click(image) ), that might be used in every parallel test workflow.

As far as I read, running the gc in between normally does not make any sense (at least with the actual versions of JRE). If memory is available, the gc runs when needed and the max values are consumed periodically. So with some profiling tool, it is necessary, to watch the minimum level, where the memory consumption should come down periodically. if this rises over time without any reason looked from your code, then it might be a memory leak in the imported stuff.

You should look into the specific options for the heap space, that are possible to define as java parameters and allow some fine tuning of heap space usage.

Revision history for this message
Bob (bwq-q) said : 		#2

Thanks RaiMan, that solved my question.

Revision history for this message
Bob (bwq-q) said : 		#3

Thanks RailMan, I will optimize the source code according to your brief.
Any further information I will let you know.
Thank you very much for your help.

Revision history for this message
Bob (bwq-q) said : 		#4

I tracked the cost memory with JProfile, I found that the most memory which could not be released was held by a static hashset named _opened. This one is managed by the class called ScreenHighlighter. Fortunately the class provide the static method to close the hashset. Every time I complete the process of the test case, I will call ScreenHighlighter.closeAll() to free memory. This time we never meet the OutOfMemoryError with JAVA again. I have solved the problem early August and just add a comment here.