-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify 2GB max heap for tests #1474
Conversation
@laeubi : could you please review? I'm not a maven/tycho expert. |
Build verification works, so it can't be that bad ;-) |
However it looks like See https://ci.eclipse.org/platform/job/eclipse.platform/job/PR-767/1/console
But that one shouldn't run with SDK / shouldn't be affected by SDK eclipse.ini changes? |
Not sure if any tests are running that use the option? At least they don't say that, searching |
That's what makes me really wonder, especially as it seems the Github Actions are not affected in the same way, so for me it looks like maybe an infra change that maven itself has insufficient resources now.
Yes tests are disabled here (because they run very long) ... my bad, so to verify one needs to run it locally or we need to temporarily remove |
But it could also be some kind of meommoryleak... I wonder if we can get a heapdum or if that will blow the Jenkins @fredg02 ? |
Enabled tests to see effect of eclipse-platform#1474
I've pushed bad commit on top (actually wanted to have different PR). Let see. |
The only way to know that would be revert #1471 and if OOM's are still there, we have a new infra/maven/tycho issue. I will do that if the experiment above (with disabling skipTests) would not show anything useful. |
And yes, we seem to have yet another infra issues: |
This seems like another pros towards redoing releng as mentioned here #1472 . If projects are really split the resources needed for each will be sufficient more often and a lot less extra configuration will be needed. |
Not sure it's related. We have some build tasks & some tests running (sometimes in parallel) on a very limited Jenkins VM with only 4GB RAM. Some tasks just don't get enough memory or have some memory leaks - how that can be related to releng/project structure? Even if we would have a single project to build and test it can get OOM if maven/tycho/whatever has a memory leak. |
If JDT and PDE build and generate their own repos and run their own tests in their own builds that would free releng.aggregator one from 100+ bundles (some of them heavy ones) thus reduce the hardware requirements to execute it. |
This is not the point here, we are probably talking about different issues. |
Maven doesn't always build modules in strict order but rather takes the first dependency order it figures which can differ from build to build, thus if you have OOM it can happen in one bundle in one run and in another on the second one and etc. Thus the solving is usually to reduce the number of modules in order to get things more predictable and manageable. |
Looks like JDT model tests are unhappy due
|
This reverts commit b0b7e79. It is possible that Jenkins test execution is affected by that change (we see some stranhe OOM errors), see comments on eclipse-platform#1474. To make sure the change doesn't cause any side effects, let revert it.
See #1475 |
That's worded wrongly, even though the end result will be the same: Maven always enforces a partial sorting that reflects all explicit dependencies, no matter which builder is used later. For other modules that don't have an explicit dependency relation, Maven will not change the order (therefore those remain in the order of declaration in the POM). Therefore the build graph (and dependency order) that Maven core dictates is the same each time. However, in multithreaded execution the builder can choose to iterate the build graph in different ways, which is what then leads to different build order when modules finish later or earlier than in other runs. My experience with OOMs in non eclipse Maven builds is that this happens especially when you have forked JVM processes and your modules are of similar size, causing parallel builds to trigger identical goals roughly at the same time. E.g. I have another Maven build with 8 threads in parallel, and the worst memory usage happens when all modules run Spotbugs or Asciidoc generation (both with forked JVM) at the same time. I'm not aware of anything that can limit the number of parallel executions of a single maven plugin (e.g. use 8 threads, but at most 4 asciidoc calls in parallel). Could this be similar? Any good ideas how to have a "semaphore" on a specific maven goal? |
5c59e6c
to
c856903
Compare
Re-opening this PR, as we see OOM's also without this change. I plan to push it once https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3896 is fixed, to not mix possible regressions coming from this PR with "other" OOM issues we see right now. |
Sorry, github mixed everything, wrong PR, wrong diff, wrong comment. |
-Xmx2g
is needed for Jenkins where RAM is low.SDK doesn't specify
-Xmx
anymore, see#1463