Bugzilla – Full Text Bug Listing
| Summary: | adjust ms, mx, and maxpermsize for unit and performance tests? | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Williams <david_williams> |
| Component: | Releng | Assignee: | David Williams <david_williams> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 4.2 | ||
| Target Milestone: | 4.3 M3 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
I don't know what it means ... but on the build.eclipse.org machine, with its limits, and using an Oracle VM (where perm size matters) there were 10837 "OutOfMemory" exceptions when trying to run the platform performance test suite. (That was with out normal unit tests running somewhat in parallel). On one of my personal machines, when trying to run the same suite, still "under Hudson" (but, master this time, not slave) I received only 88 OutOfMemory exceptions ... that was using an IBM VM where "perm size setting" doesn't matter. Of course, my personal machine did not have a small "overall" memory limitation so suspect that's most of it ... but ... bit difference! And, 88 is still a lot! So, I think first step is getting properly configured virtual machine to run windows tests on before deciding anything else. Appears we might have to increase heap to help the 88 cases I'm seeing locally? Denis tells me the current windows7test machine has LOTS of memory associated with it (5G) so I'm going to set it to 1 executor and re-try our performance tests. But ... makes me wonder ... the different in what I see with IBM VM and results on windows7test machine (where Oracle "perm gen" space is used) makes me wonder if that's part of what accounts for reports of "peformance problems" from community that "we" can't seem to reproduce? I seem to recall its possible to "leak classes" that fill up perm gen space? Interesting, according to http://javaeesupportpatterns.blogspot.com/2011/10/java-7-features-permgen-removal.html There is no "perm space" in (Oracle/Sun's) JVM 7 any longer. Though, they say "it will take several releases of Java 7 to get rid of it completely". I think we have jdk7u2 on windows machine, and appears they are up to u7 by now. Perhaps we should ask for an update? (bug 390286) 500M seems like a lot for perm gen. I recall in the distant past a problem with Ant class loaders leaking that would eat up perm gen space, but still 500MB sounds like a lot. Unless we are specifically getting PermGen errors in the performance tests I think trying a reset to default is reasonable. On the other hand, 512MB for heap does not sound like a lot, assuming we are running 64-bit Eclipse. I believe our performance tests always ran on 32-bit in the past, we could easily need much more, perhaps even double. Some of the perf tests operate on large data sets, and if we have even small leaks when we open/close a part 10,000 times it can add up. Thanks for your comments, John. I've adjusted library.xml so that unit tests match what we currently use in "eclipse.ini" -Xms40m -Xmx512m -XX:MaxPermSize=256m And for the performance tests did basically double max heap and greatly increased "minimum heap". The idea being that while garbage collection is an important part of "real life" performance, we don't want want out performance tests to be overly influenced by it, since we are trying to test for specific regressions, not GC behavior, per se. -Xms512M -Xmx1024M -XX:MaxPermSize=256m I lowered MaxPermSize to what we have in eclipse.ini, so we'll see if we start getting errors due to that; but sounds like we won't. http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=2d5e9badd8aacd7c7a14e9dca74401d1d0d25c2e Note, these won't start to show up in our current tests of tests of performance tests; Only once we get a rebuild of the org.eclipse.test infrastructure. Just wanted to document I have seen an java.lang.OutOfMemoryError: PermGen space on a test linux box for the performance test: org.eclipse.pde.api.tools.tests.ApiToolsPerformanceTestSuite.txt But this was using build I20120920-1300 which didn't even have the change it in (pretty sure) ... so ... there might have been a reason for the very high value? I'll leave this closed for now, and re-open if I see again on more recent builds. mass change to 'verified', as these bugs are either routine or obviously fixed build breaks. |
Technically, this is two issues ... but ... 1. for performance tests, we use <condition property="vmargs" value=" -Xms256M -Xmx512M -XX:MaxPermSize=500m ${envantopts}" > <equals arg1="${test.target}" arg2="performance" /> </condition> MaxPermSize seems kind of excessive? This might be why we are hitting lots of "out of memory, can't create native thread" problems on virtual machines on build.eclipse.org. Granted, those machines are currently severely limited (to 1 Gig? 2?, we've asked for 4) but still ... anyone recall why 500m was used? I'd think we'd want it to "match" what ever we typically "ship" with, which for 4.2 is --launcher.XXMaxPermSize 256m -vmargs -Xms40m -Xmx512m 2. for regular junit tests we seem to still be using "old" values of max heap of 384. Not sure this is causing a problem, per se, but ... seems we'd want it to be the same as "what we ship"? (In fact, we did, apparently, used to use "eclipse.exe" for unit tests which would use what was in eclipse.ini, but no longer do (see bug 387638). Unless someone recalls some history behind this decision, I'd prefer to "reset" to use what we ship with (for 4.2) and adjust as we find reason to. I could not find anything obvious in releng bugs that would explain it. These are all set in "library.xml". So, I suggest <condition property="vmargs" value=" -Xms40M -Xmx512M -XX:MaxPermSize=256m ${envantopts}" > <equals arg1="${test.target}" arg2="performance" /> </condition> and for unit tests <condition property="vmargs" value=" -Xms40m -Xmx512m -XX:MaxPermSize=256m ${envantopts}"> <os family="windows" /> </condition> <property name="vmargs" value=" -Xms40m -Xmx512m -XX:MaxPermSize=256m ${envantopts}" />