UpdateSitePublisher -addJREIU argument doesn't add current JVM

[iloveeclipse]

Don't hard code "default" JRE version if we "guess one" and create some profile based on current JRE packages. Just read & use the version from the running JRE.

Fixes https://github.com/eclipse-equinox/p2/issues/461

[github-actions[bot]]

Test Results

    9 files  ±0      9 suites  ±0   29m 52s :stopwatch: - 4m 57s 2 183 tests ±0  2 179 :white_check_mark: ±0   4 :zzz: ±0  0 :x: ±0  6 639 runs  ±0  6 628 :white_check_mark: ±0  11 :zzz: ±0  0 :x: ±0 

Results for commit b5f17167. ± Comparison against base commit 4327aa9c.

:recycle: This comment has been updated with latest results.

[iloveeclipse]

Build fails with org.eclipse.equinox.p2.tests: Error assembling JAR: Problem creating jar: Execution exception: Java heap space. is this something that changed recently?

[laeubi]

Please add https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/.mvn/jvm.config to this repository as well, it should help with that OOM errors as currently only 1GB of 4G is used by default.

[iloveeclipse]

Please add https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/.mvn/jvm.config to this repository as well, it should help with that OOM errors as currently only 1GB of 4G is used by default.

We surely won't have that workaround be forever, is there a ticket for that so I can link the PR against?

[laeubi]

Please add https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/.mvn/jvm.config to this repository as well, it should help with that OOM errors as currently only 1GB of 4G is used by default.

We surely won't have that workaround be forever, is there a ticket for that so I can link the PR against?

If you mean we should stop development once we hit 1gb of memory demands then no there is no such ticket, beside that we don't get an refund if we only use 1/4 of available memory.

[iloveeclipse]

If you mean we should stop development once we hit 1gb of memory demands then no there is no such ticket, beside that we don't get an refund if we only use 1/4 of available memory.

I'm only asking for the root issue here, that requires now this workaround.

[laeubi]

If you mean we should stop development once we hit 1gb of memory demands then no there is no such ticket, beside that we don't get an refund if we only use 1/4 of available memory.

I'm only asking for the root issue here, that requires now this workaround.

I have recently analyzed the build and didn't find any unusual memory consumption, so the root cause seem that we are use more features, doing more checks and so on takes more memory so we hit a limit. As long as we are not really hitting the limit (e.g. need more and more and finally getting killed) I won't analyze further. So if 2g works for the next 20years its a bit of waste of dev resources otherwise.

If you are interested, you can run the build local with -Xmx=1g (the current default) and let you produce a heapdump and look for possible optimizations in platform/jdt(I already made some) or tycho/maven (e.g MNG-7592.