[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] timeout
|
Hi Stephan,
I imagine that max heap default to -Xmx1024m used for SDK is too less
for the old + new index, and that the GC has hard times to free the
memory like in bug 512749 (java.lang.OutOfMemoryError: GC overhead limit
exceeded).
I had already reported this via bug 511693, that for my personal setup
the memory consumption seem to be doubled in 4.7. I don't see OOM errors
but only because I have max heap increased to 3G. In my typical setup,
in the idling Eclipse with ~10 opened editors and lot of Platform
projects in the workspace, JDT uses 520 from 804 MB (used by the JVM),
and more then a half of that (270 MB) is used by the
org.eclipse.jdt.internal.core.nd.db.Chunk objects.
But of course it can be that jdt Hudson has some issues. Have you tried
to restart it (in case Hudson leaks some memory or file descriptors or
both)?
Am 27.02.2017 um 20:44 schrieb Stephan Herrmann:
Hi folks,
Gerrit is of very little help these days, timing out more often then not.
Of the last 15 runs, only one succeeded (#2462), which contained this:
----
combined with:
Bug 512740: [newindex] preference to disable the new index does not
disable its rescan job
AND: HARD-DISABLE the new index for now
----
Is that just a coincidence or is the new index really causing our tests
to time out?
(Locally on my machine tests almost always hang during AllJavaModelTests
if the new index is enabled).
Or has s.t. else in the stack degraded in performance?
Some random references to candidate culprits:
HIPP:
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14119.html
OOME: https://bugs.eclipse.org/bugs/show_bug.cgi?id=512749
Seeing the compiler in the stack reminds me also of:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=512156
any theories?
Stephan
--
Kind regards,
Andrey Loskutov
http://google.com/+AndreyLoskutov
