Community
Participate
Working Groups
we use org.eclipse.jdt.core.dom.ASTParser.createBindings(IJavaElement[], IProgressMonitor) inside Xtext to retrieve bindings for ITypes. When running code with Xtext 2.13 with Oxygen 1a and a Java 9 Plugin Project Zoo we see a performance drop compared to Java 8 / Pre Oxygen 1a even with the patch / cache for #526209 applied. you can find a yourkit snapshot here: https://drive.google.com/open?id=0B7rqwXB52fUOM1prTkRpWFJQV00
Created attachment 271198 [details] Example Project that reproduces the problem
(In reply to Christian Dietrich from comment #1) > Created attachment 271198 [details] > Example Project that reproduces the problem Thanks, I can reproduce long build time using that example.
If memory serves me right, then according to YourKit a hotspot is in org.eclipse.jdt.internal.core.SearchableEnvironment.getModulesDeclaringPackage(char[][], char[], char[]) where it calls isPackage() right? First observation in this area: for each invocation of ASTParser.createBindings() there are some tens of invocations where some toplevel packages are searched in all modules on the path. Non-toplevel packages trigger getModulesDeclaringPackage fewer times, but here we invoke NameLookup.isPackage() for each known package fragment root. This happens because we are looking from an unnamed module and hence don't have a module that could restrict the search scope. I still need to investigate more, but I haven't yet found any redundant lookup and the above could well indicate that all/most of this is intrinsic new complexity in Java 9: we need to check for each referenced package whether it is uniquely visible, ergo stopping at the first hit is not an option. If this theory can be confirmed, than we should put our money on bug 526520, rather than tweaking the implementation around SearchableEnvironment & NameLookup.
Should decide early in 4.9 if we invest here, or put our money on bug 526520.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
