Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 36956 - [plan item] Allow plug-in deactivation
Summary: [plan item] Allow plug-in deactivation
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 2.1   Edit
Hardware: All All
: P4 enhancement with 2 votes (vote)
Target Milestone: 3.0   Edit
Assignee: Jeff McAffer CLA
QA Contact:
URL:
Whiteboard:
Keywords: plan
Depends on:
Blocks:
 
Reported: 2003-04-25 18:19 EDT by Jim des Rivieres CLA
Modified: 2004-04-15 11:14 EDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jim des Rivieres CLA 2003-04-25 18:19:12 EDT
Allow plug-in deactivation. In order to scale to a large number of plug-ins, 
Eclipse does not activate a plug-in until its code is actually needed. 
However, once activated a plug-in remains active for the remainder of the 
session. Unfortunately, this means that an active plug-in will occupy memory 
space for its code and objects even if it is only used occasionally. Many 
users have sessions lasting days or weeks, and this bloat taxes processor 
memory and JVM performance. The analogy is a long play where the actors enter 
the stage on cue, but cannot leave it until the play is over. The Eclipse 
Platform should support plug-ins that can be safely deactivated when the user 
needs to recover valuable memory space. Another alternative is to provide a 
way to quietly shutdown and restart the Platform. [Platform Core, Platform UI] 
[Theme: Rich client platform]
Comment 1 DJ Houghton CLA 2004-04-15 09:34:42 EDT
Plug-in deactivation is now a part of the SDK with the availability of the new
OSGi based runtime.

Moving to JM for comment/closure.
Comment 2 Jeff McAffer CLA 2004-04-15 11:14:29 EDT
The new Eclipse runtime allows plugins to be stopped at various points during a 
session.  Furhter work is needed by plugins at large to become dynamic aware in 
that they should forget about plugins that are going away.  Without this, the 
memory allocated to a deactivated plugin (e.g., though its classloader) will 
not be recovered.

This work will be incremental and ongoing over future releases.