Start
Level: Advanced
Dan kehn
Software engineer, IBM 2004 April
This article describes one of the core tools (Core Tools) obtained from ECLIPSE.ORG:
Runtime SPY. Runtime SPY is a perspective view and a set of views that help you find and diagnose plug-in boot performance issues.
We will hear a new company almost every day to choose Eclipse as their application development platform. Although all of these companies' products (more don't say all Eclipse organizations) installation settings may be the same, but the risk of excessive memory use and performance drop is still great. This article describes a very useful tool, Runtime Spy to help plug-in developers. The Runtime Spy perspective is part of the Core Team Detective and Tools (Spries and Tools) group (in the Reference Download Download Link).
Note: Core tools can only run in Eclipse version 2.x. In this article, they cannot run on the Eclipse 3.0 driver; BUG numbered 47518 describes this issue.
Why Eclipse needs to quickly start the Eclipse architecture is designed to expand its environment in the running period. This system structured extension enables many tools to be seamlessly integrated into Eclipse. The Eclipse architect realized early in the project that these extensions could not be defined in the client code, because when Eclipse integrates more and more extensions, the accumulated startup overhead will become unacceptable. Thus, these extensions are defined by the plugin.
In order to avoid starting overhead while maintaining flexibility, the plug-in is static to define its extension in a manifest file. The plug-in list defines enough information so that the Eclipse platform can delay the loading code while still identifying the initial impact of the extension. For example, a user interface extension requires sufficient information to depict the initial user interface element (eg, the icon of the supplied toolbar and the Tooltip) text, which can post the loading of the plugin code until the user is truly Select a menu option to select a toolbar button to open a property page or start a wizard. The initial overhead of the plug-in is just a resolution of its list. The XML format is resolved very quickly, and the results are saved to the disk. This will be used next time, so that when new plugins or expansions are defined, startup will not be significantly affected. However, there are some ways to unintentionally invalidate this benefit, thereby increasing startup time and memory consumption.
Fortunately, Eclipse plug-in developers can use the Runtime Spy perspective to help track these issues. This article describes the core tool plug-in and its runtime spy, and introduces some of the scattered descriptions of the ReadMe file (see Resources).
Installing the core tool installation is simple. Just download the core tool compression package and unzip it to your
First, copy the .Options file to your
Detective Table We assume that you have already installed the core tool file and restart Eclipse. Since the -debug command line parameters have been specified, you will see some boot messages directed to the standard output. When in debug mode, these will appear in a separate command prompt window, as shown in Figure 1.
Figure 1. Open a command prompt window for displaying a standard output message on the specified of the -debug option.
Since each Runtime SPY is started and run, let's quickly browse these views. Don't forget, SPY runs as a "SPIED" plugin in the same workstation, so some plugins may be activated during the normal process of using the tool itself. This usually doesn't matter, because it is just a function of the underlying, and these functions should have been loaded or loaded sooner or later. There is no necessity, but it is indeed important, that is, don't forget that it is updated as needed, so when the Runtime Spy perspective is opened for the first time, it will only show it before it starts. It is already running. Those plugins.
See which plugins Open four views in Run Select Window> Open Perspective> Runtime SPY, as shown in Figure 2.
Figure 2. Runtime Spy perspective consists of ActiVated plugins, loaded classes, plugin datasheet, and stack trace view
If you have forgotten the specified -debug option, you will see the "Plugin Monitoring IS Not Enable" message in the Activated Plugins view. Since the default is not class being monitored, the Load Classes view will contain the "Class Monitoring IS Not Enabled" message. Capture of the product will slow down, so you must list those classes by specifying the packages or plugins that contain classes you are interested in. Now we just care about which plugins are loaded. Figure 3 shows the main view of Runtime SPY, ActiVated Plugins.
Figure 3. ActiVated plugins view displayed in Runtime SPY
If you want to display memory usage statistics (Alloc, Used, and ROM Used columns) in the Runtime SPY view, you must use the IBM Java running period environment (Runtime Environment) that supports J9 technology. This JRE is included in IBM version Eclipse called WebSphere Studio Workbench, you can download it for free after IBM PartnerWorld For Developers (you can find a link in the reference). Remember to specify J9 as a parameter (for example, eclipse -debug -vmargs -xj9) of the Java runtime environment. Click on the title of the first column, plugin, will be sorted to ascending, descending, and packet ascending order. The plug-in in the " " number is the plugin that needs to be run when the parent plugin is running. When the loaded plug-in is packet, the value of the row corresponds to the plugin and all the sub-plugins. This sort can be used when you want to view heavyweight (resource) to view with a group.
The plug-in name with an asterisk is those that are loaded when starting. Regardless of the name, the Activated Plugins view is marked in the Activated Plugins view, which does not include those plugins that the workbench processing it is loaded with its org.eclipse.ui.startup extension. More specifically, the table is to handle these extensions after initial startup.
Special interesting is the Order column. Click on the title of this column to order the plugin list to load order. If you want to quickly view a given action activation which plugin, first select all plugins (Ctrl a), execute the action, then return to the ActiVated Plugins view, then select the button. Not selected is the plugins that are just activated. Another method is that the last plugin of the record is already running in your action, and then updates to see those sorted plugins.
See which classes of the plugin are loaded by the plug-in is loaded as needed. You may save memory and start time by delaying these references or decreases references to some classes. Loaded Classes view will help you see which classes have been loaded until now. To update the loaded classes view, select one or more plugins in the ActiVated Plugin list, then select the button. Displayed in Figure 4 is a class that the ORG. ECLIPSE.JDT.CORE plugin has loaded to load order.
Figure 4. Loaded Classes view displayed in Runtime SPY
In addition to the mode of the plug-in, I found that by sorting the reference order, this view can also be used to obtain a given action initialized class and sequence "Big Picture". In this list, the plugin startup code is included, so you can fully realize the cost of executing it. This story is usually "too much to start".
Tracking a class why is loaded to be more clearly understood What causing a plug-in activation or a class load, first you have to enable tracking options for the plugin or package where you causing your attention. In this example, I created a traces.properties file, one of the lines for packages = org.eclipse.jface.text. Then you need:
Select the org.eclipse.jface.text plugin in the ActiVated Plugins list. Press the button to update the Load Classes list. Select the org.eclipse.jface.text.itextViewer class. The STACK TRAC is updated to update the button. This will display which code allows the class loader to load the class (if it is not loaded before this, it has not been loaded) and activates the selected plugin, as shown in Figure 5.
Figure 5. Stack TRACE view displayed in Runtime SPY
The top of the stack is usually not worth paying, because the tracking is the class loader code itself. Useful information is in the middle and lower part. In this example, the stack record is displayed due to the opening of the Runtime SPY perspective, and ultimately leads to the load of the ITextViewer class, as shown in the bottom of the highlighted stack record. The PLUGIN DATASHEET view is included in the perspective, which will display its data with the JFACE Text class TextViewer. When you verify that class during DefineClass, the JVM discovery requires ITextViewer because TextViewer implements this interface. If you can see, the class load of the JVM running period can be nestled quite deep; for performance purposes, you should usually pay attention to the code that causes the class loader call, the highlighted portion of the stack recorded in Figure 5.
The tracking plug-in is loaded on an example indicates why a particular class is loaded. You can also view why a given plugin is loaded, but the reasons for the plugin active looks not so obvious because the cause is indirect. In general, the class is loaded due to the method referenced by another class (and you can also refer to the corresponding IMPORT statement), with the difference, the loading of the plugin is some of the results of indirect reference. Don't forget, our purpose is that when the plugin is used, try not to load it, so the reference to the plugin itself is true:
Declaring the identity, such as
These two examples are highlighted in the "Hello, Eclipse" plugin list, see Listing 1.
Listing 1. Extension Point of "Hello, Eclipse"
... line omitted ...
... line omitted ...
Label = "Sample Action SET" Visible = "True" ID = "Hello.actionSet"> ID = "SampleMenu"> Name = "SampleGroup"> Label = "& Sample Action" icon = "icons / sample.gif" Class = "Hello.Anch.sample" Tooltip = "Hello, Eclipse World" MenuBarpath = "SampleMenu / SampleGroup" Toolbarpath = "SampleGroup" id = "hello.actions.sampleAction"> Contribution to org.eclipse.ui.ActionSets extended point action settings is implicitly demonstrated to define the plugin, which is the Workbench UI plugin (org.eclipse.ui). The Workbench plugin will read the plug-in registry, which contains this contribution to its org.eclipse.ui.ActionSets extension and creates the corresponding action settings. The SampleAction class will not be loaded here, so that the plugin containing it will not be loaded. Instead, the Workbench plug-in defines a delegate action to represent the selection in the user interface, and this delegate action will wait until the user actually selects it to create an instance of SampleAction to process the response. In order to create an instance of SampleAction, the action representation calls the CreateExecutableExtension method of the plug-in registry instance iConfigurationElement, corresponding to the Figure 6. The Stack TRACE view shows the startup of the executable extension In this example, we can see the bottom of the stack record highlights, which are double-clickers from the PDE's PLUG-INS view. The default action handler is responsible for processing the action request Workbench to open the PLUG-IN Manifest Editor, then activate the org.eclipse.ui.editors plugin. The highlighted part of the stack is just a code that extends the extension processor because it is indirect to the reference to the Workbench plugin class (org.eclipse.ui). Through six similar stack records, you will identify the important part of the IconFigurationElement.createExecutableExtension call, and soon see who is starting it and what is the result. You can select the button to update the loaded class and re-press the loading order to better understand what happened after the plugin is started. Other useful views Finally, the Plugin Datasheet view summarizes some interesting statistics, such as how much resources and extensions defined, as shown in Figure 7. Figure 7. Plugin Datasheet displays the resources used This view tracks the resource bundle data loaded by the iplugindescriptor.getResourceString method and its variable. This summary information has benefited from such a fact that the Eclipse platform has its own class loader, and the class loader is dealing with the resource bundle like the class, so it is very simple to keep track of resource data statistics. "Not loaded yet" message indicates that the plugin registration table is written on disk, and the part there is only to load when needed. The underlying facilities of the detective Eclipse itself were introduced to the front section of the detective period workbench. More practical is, you will want to detective beta workbench, called the runtime workbench. You can select Run> Run as ...> Run-Time Workbench and go to the TRACING page to configure an instance of the running scheduled workbench you wish to start, as shown in Figure 8. Figure 8. Set the Runtime SPY option in the TRACING page Org.eclipse.core.boot The debugging option is also located in the Additional Information You can find a lot of information about Java performance adjustment, but rarely specifically for Eclipse. This article introduces you the tools for understanding and diagnosing the best tools for start-up performance issues. Before the end, it is necessary to pay attention to some of the other useful diagnostic information provided to you: Plug-in Dependency Perspective Display Information Similar to the information displayed in the Plug-in Registry view (via Window> Show View> Other ...> PDE Runtime> Plug-in Registry), but with a selection plugin Detailed list of relying on plugins. Is there anything in the Metadata directory that considers workspace? Metadata perspective will help you roam in its structure. However, premise is to have a considerable understanding of work space. A class of RESource Tools views describe insights for resource change listeners and Resource delta, Builder, and more. Those who learn work space API should pay particular attention to Resource, Delta, and Builder / Listener view. Select Window> Show View> Other ...> Resource Tools to access these views. You can learn more about these tools in the README of the core tool (see References).
