[JBoss JIRA] (ERT-666) Improve JDT Indexer performance for method reference lookups
by Roland Grunberg (JIRA)
[ https://issues.jboss.org/browse/ERT-666?page=com.atlassian.jira.plugin.sy... ]
Roland Grunberg updated ERT-666:
--------------------------------
Description:
Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer.
One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format.
The methodRef category table currently stores :
(symbol, number of arguments) -> document numbers (classfiles)
toString/0 -> [1, 4, 5, 25]
The proposal would change this to :
(symbol, symbol's classname, classname) -> document numbers (classfiles)
toString/0/java.lang.Object -> [1, 4, 5, 25]
Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference.
(/) Make the patch mostly correct
(/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString()
(?) Detect method references even in dead code (this is supported by existing indexer)
(?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString()
(?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() )
was:
Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer.
One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format.
The methodRef category table currently stores :
(symbol, number of arguments) -> document numbers (classfiles)
toString/0 -> [1, 4, 5, 25]
The proposal would change this to :
(symbol, symbol's classname, classname) -> document numbers (classfiles)
toString/0/java.lang.Object -> [1, 4, 5, 25]
Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference.
(/) Make the patch mostly correct
(/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString()
(?) Detect method references even in dead code (this is supported by existing indexer)
(?) Detect method references in comments (annotations) (this is supported by existing indexer)
(?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString()
(?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() )
> Improve JDT Indexer performance for method reference lookups
> ------------------------------------------------------------
>
> Key: ERT-666
> URL: https://issues.jboss.org/browse/ERT-666
> Project: Eclipse Release Train
> Issue Type: Task
> Reporter: Roland Grunberg
> Assignee: Roland Grunberg
>
> Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer.
> One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format.
> The methodRef category table currently stores :
> (symbol, number of arguments) -> document numbers (classfiles)
> toString/0 -> [1, 4, 5, 25]
> The proposal would change this to :
> (symbol, symbol's classname, classname) -> document numbers (classfiles)
> toString/0/java.lang.Object -> [1, 4, 5, 25]
> Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference.
> (/) Make the patch mostly correct
> (/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString()
> (?) Detect method references even in dead code (this is supported by existing indexer)
> (?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString()
> (?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() )
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBIDE-25000) Server adapter: starting into debugging fails initially (succeeds on a latter try)
by Mohit Suman (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25000?page=com.atlassian.jira.plugi... ]
Mohit Suman updated JBIDE-25000:
--------------------------------
Story Points: 13 (was: 16)
> Server adapter: starting into debugging fails initially (succeeds on a latter try)
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-25000
> URL: https://issues.jboss.org/browse/JBIDE-25000
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.5.0.AM2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3, server_adapter
> Fix For: 4.9.x
>
> Attachments: failed-to-connect-v8-vm.png
>
>
> # ASSERT: have an application running in *[OpenShift Online|https://console.starter-us-east-2.openshift.com/]* based on the "nodejs-mongo-persistent" template
> # ASSERT: have a server adapter for it
> # EXEC/ASSERT: have the adapter started in non-debugging/normal mode
> # EXEC: restart the adapter debugging
> Result:
> !failed-to-connect-v8-vm.png!
> {code}
> java.io.IOException: Failed to get version
> at org.eclipse.wst.jsdt.chromium.internal.v8native.JavascriptVmImpl.newIOException(JavascriptVmImpl.java:114)
> at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attachImpl(StandaloneVmImpl.java:132)
> at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attach(StandaloneVmImpl.java:79)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.JavascriptVmEmbedderFactory$4$1.attach(JavascriptVmEmbedderFactory.java:207)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.DebugTargetImpl.attach(DebugTargetImpl.java:74)
> at org.eclipse.wst.jsdt.chromium.debug.ui.launcher.LaunchTypeBase.launch(LaunchTypeBase.java:101)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1039)
> at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1256)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> Caused by: java.util.concurrent.ExecutionException: java.io.IOException: End of stream
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl.attachImpl(StandaloneVmImpl.java:127)
> ... 9 more
> Caused by: java.io.IOException: End of stream
> at org.eclipse.wst.jsdt.chromium.internal.transport.Handshaker$StandaloneV8Impl$HandshakeTaks.call(Handshaker.java:127)
> at org.eclipse.wst.jsdt.chromium.internal.transport.Handshaker$StandaloneV8Impl$HandshakeTaks.call(Handshaker.java:1)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.eclipse.wst.jsdt.chromium.internal.transport.Handshaker$StandaloneV8Impl.perform(Handshaker.java:104)
> at org.eclipse.wst.jsdt.chromium.internal.transport.SocketConnection$ReaderThread.run(SocketConnection.java:158)
> {code}
> ps. this can be simulated in the CDK, by having everything set and once the pod is up and ithe adapter is in debug, stopping the port forwarding.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBIDE-25830) After starting CDK server adapter OpenShift Connection does not work when oc is not on path
by Mohit Suman (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25830?page=com.atlassian.jira.plugi... ]
Mohit Suman updated JBIDE-25830:
--------------------------------
Story Points: 8
> After starting CDK server adapter OpenShift Connection does not work when oc is not on path
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-25830
> URL: https://issues.jboss.org/browse/JBIDE-25830
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: cdk, openshift
> Affects Versions: 4.5.3.AM3
> Reporter: Josef Kopriva
> Assignee: Andre Dietisheim
> Labels: cdk_server_adapter, connection
> Fix For: 4.9.0.Final
>
> Attachments: edit-connection-advanced.png
>
>
> OpenShift connection should be working, when user starts CDK server adapter, even if you do not have oc on path. In my opinion OpenShift connection should be working "out of box" when user starts CDK server adapter.
> steps:
> # ASSERT: oc is not on path
> # EXEC: Start CDK server adapter
> # ASSERT: OpenShift connection is created, but does not fully work (all oc related operations wont)
> Error: oc is not set for OpenShift connection to CDK and OpenShift connection does not work.
> Expected: OpenShift connection should be working without user touch.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBDS-4730) Use "CodeReady Studio" instead of "Red Hat Developer Studio" in graphics & text
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4730?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-4730:
----------------------------------
Thanks. I believe the name is only CodeReady Studio, not Red Hat CodeReady Studio, but they'll know best. :D
> Use "CodeReady Studio" instead of "Red Hat Developer Studio" in graphics & text
> -------------------------------------------------------------------------------
>
> Key: JBDS-4730
> URL: https://issues.jboss.org/browse/JBDS-4730
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Task
> Components: build, installer
> Affects Versions: 12.9.0.AM3
> Reporter: Nick Boldt
> Assignee: James Cobb
> Priority: Blocker
> Fix For: 12.10.0.AM1
>
>
> Branding has requested that we rename devstudio from "Red Hat Developer Studio" to "CodeReady Studio".
> As we did recently in JBDS-4706, we'll need to collect graphics for use in the product and its website on https://devstudio.redhat.com/12/staging/updates/
> We'll need this rebrand done for the upcoming December release. All changes need to be done by November 6 so they can be included in the AM1 feature complete release on Nov 13, in support of the docs team, updating screenshots, install instructions, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBDS-4730) Use "CodeReady Studio" instead of "Red Hat Developer Studio" in graphics & text
by James Cobb (JIRA)
[ https://issues.jboss.org/browse/JBDS-4730?page=com.atlassian.jira.plugin.... ]
James Cobb commented on JBDS-4730:
----------------------------------
[~nickboldt] - I'll reach out to Brand and see if they have the official logotype for "Red Hat CodeReady Studio"
> Use "CodeReady Studio" instead of "Red Hat Developer Studio" in graphics & text
> -------------------------------------------------------------------------------
>
> Key: JBDS-4730
> URL: https://issues.jboss.org/browse/JBDS-4730
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Task
> Components: build, installer
> Affects Versions: 12.9.0.AM3
> Reporter: Nick Boldt
> Assignee: James Cobb
> Priority: Blocker
> Fix For: 12.10.0.AM1
>
>
> Branding has requested that we rename devstudio from "Red Hat Developer Studio" to "CodeReady Studio".
> As we did recently in JBDS-4706, we'll need to collect graphics for use in the product and its website on https://devstudio.redhat.com/12/staging/updates/
> We'll need this rebrand done for the upcoming December release. All changes need to be done by November 6 so they can be included in the AM1 feature complete release on Nov 13, in support of the docs team, updating screenshots, install instructions, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months