Home » Eclipse Projects » Eclipse Platform » lazy deinitialization
| lazy deinitialization [message #247531] |
Mon, 31 May 2004 13:12  |
Eclipse User |
|
|
|
Originally posted by: sergiy.dubovik.leiki.fi
Hi,
Started to explore Eclipse last month and have a question to which
I can't find an answer. Eclipse uses lazy initialization pattern
for plugins and preferences. Very good idea. But once they initialized
they remain in the memory until I close Eclipse even though I don't
use preferences or plugin anymore.
The question is why there is no feature which will deactivate plugins
if they are not in use for some period of time? Or may be I'm wrong?
Sergiy
|
|
| |
| Re: lazy deinitialization [message #248182 is a reply to message #247531] |
Wed, 02 June 2004 02:57  |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
We don't have "automatic" deactivation support because detecting usage
and therefore not usage is not trivial. For example once a plugin has
been started most a lot of calls are done directly through various apis.
Does it mean that we should instrument all the apis to keep plugins
alive? You could also watch if the plugin of the model changes, etc...
What happens when you take a break and half of your plugins has
disappeared? Should the UI of the plugins go away?
Basically so far the main focus has been put on the infrastructure to
support deactivation/unload of plugins, and the trigger of deactivation
is left to the user.
Note that we are interesting by ideas, heuristics, etc.
PaScaL
Sergiy Dubovik wrote:
> Hi,
>
> Started to explore Eclipse last month and have a question to which
> I can't find an answer. Eclipse uses lazy initialization pattern
> for plugins and preferences. Very good idea. But once they initialized
> they remain in the memory until I close Eclipse even though I don't
> use preferences or plugin anymore.
>
> The question is why there is no feature which will deactivate plugins
> if they are not in use for some period of time? Or may be I'm wrong?
>
> Sergiy
|
|
|
| Re: lazy deinitialization [message #248236 is a reply to message #248182] |
Wed, 02 June 2004 08:15 |
 Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Pascal is correct for the most part. I believe it could be possible to a
degree. Within a classloader of a plugin you could keep track of all classes
found within the classpath of the plugin and set a marker of what time it
was accessed. Have a separate thread check all the plugins at periodic
rates, checking this value. The problem is, this value would only be updated
when a class is first looked for. There is no telling what plugins may be
doing with the class after it's found. I don't know for sure, but pretty
sure once the JVM has found a class, it has it's own internal map or cache
of the class:classloader so that it no longer asks the classloader to find a
class. I am really not sure if there is a way to crack in to the JVM's
internals to "watch" class activity or not, especially without some sort of
degradation of performance.
If a plugin used it's own classes and that was it, and no other plugin used
those classes, it could be possible for a plugin to deactivate itself after
some time in some manner. But this is not the case, so like Pascal said, I
think it's pretty impossible to be able to deactivate a plugin unless you
find some way to watch all class activity for a plugin's classes, including
new instances of it or anything the GC may reclaim... destruction of a class
instance. Maybe an AOP framework can do this...not sure?
Still, like Pascal said, what happens to GUI based plugins. If they
deactivate, their GUI usually would go away. Maybe if they build upon an
actionSet their menuitem stays, so that when its clicked on it re-activates
the plugin. But I don't see how this would be possible otherwise.
"Pascal Rapicault" <pascal@ibm.canada> wrote in message
news:c9jf7u$h59$1@eclipse.org...
> We don't have "automatic" deactivation support because detecting usage
> and therefore not usage is not trivial. For example once a plugin has
> been started most a lot of calls are done directly through various apis.
> Does it mean that we should instrument all the apis to keep plugins
> alive? You could also watch if the plugin of the model changes, etc...
> What happens when you take a break and half of your plugins has
> disappeared? Should the UI of the plugins go away?
>
> Basically so far the main focus has been put on the infrastructure to
> support deactivation/unload of plugins, and the trigger of deactivation
> is left to the user.
>
> Note that we are interesting by ideas, heuristics, etc.
>
> PaScaL
>
> Sergiy Dubovik wrote:
>
> > Hi,
> >
> > Started to explore Eclipse last month and have a question to which
> > I can't find an answer. Eclipse uses lazy initialization pattern
> > for plugins and preferences. Very good idea. But once they initialized
> > they remain in the memory until I close Eclipse even though I don't
> > use preferences or plugin anymore.
> >
> > The question is why there is no feature which will deactivate plugins
> > if they are not in use for some period of time? Or may be I'm wrong?
> >
> > Sergiy
|
|
|
| Re: lazy deinitialization [message #248760 is a reply to message #248182] |
Thu, 03 June 2004 11:48 |
| Eclipse User |
|
|
|
Originally posted by: sergiy.dubovik.leiki.fi
Pascal Rapicault wrote:
> We don't have "automatic" deactivation support because detecting usage
> and therefore not usage is not trivial. For example once a plugin has
> been started most a lot of calls are done directly through various apis.
> Does it mean that we should instrument all the apis to keep plugins
> alive? You could also watch if the plugin of the model changes, etc...
No, of coarse plugin instrumentation is not a good idea.
> What happens when you take a break and half of your plugins has
> disappeared? Should the UI of the plugins go away?
I was thinking about more simple case. Plugin is a singleton. Once
it initialized, static variable keeps it out from GC hands. If it not
in use, I thought Eclipse can tell to plugin to remove that reference
and GC will release memory. But now I see that it's not that simple
because of UI, callbacks etc.
> Basically so far the main focus has been put on the infrastructure to
> support deactivation/unload of plugins, and the trigger of deactivation
> is left to the user.
I appriciate this very much :)
> Note that we are interesting by ideas, heuristics, etc.
Here is more detailed strategy. What if the deactivation logic will be
moved from Eclipse to plugin? In WinCE, when PDA does not have enough
memory OS sends to application several events like this: "We are running
out of memory, try to delete caches, buffers etc", "We ran out of
memory, save data if possible and exit", "You will be killed right now".
What if the same approach can be applied to Eclipse's plugins? Eclipse's
routine can be triggered from time to time to broadcast similar events
to plugins and then they take care about the rest. It shouldn't add
more problems to plugins' writers.
Those triggering events can be:
- amount of memory user wants to provide for Eclipse. It's not as
strict as -Xmx, just a wish: try to use no more than 256M. When
Eclipse reaches this point it send events to plugins.
- every X minutes.
Couple of use cases.
XML Editor.
In my work I don't use it too often. May be several times per day.
Mostly to change version number, to add a library to ant file or
to edit web.xml (let's assume it's the same editor). With this,
or similar approach Eclipse could have X bytes for other more
important needs.
JSP Editor is almost the same story. Sometimes you work whole day
with it, but sometimes you need just to add ';' in the end of the line.
'Partial deactivation' can be quite usefull too. For instance if you
have many open files, you don't need to keep AST of a file which
is not visible. It's faster to recostruct it from source, then to
load from swap file.
and so on.
Does it make sense?
I'm going to try Eclipse under JProfiler and see where memory
goes.
Sergiy
> PaScaL
>
> Sergiy Dubovik wrote:
>
>> Hi,
>>
>> Started to explore Eclipse last month and have a question to which
>> I can't find an answer. Eclipse uses lazy initialization pattern
>> for plugins and preferences. Very good idea. But once they initialized
>> they remain in the memory until I close Eclipse even though I don't
>> use preferences or plugin anymore.
>>
>> The question is why there is no feature which will deactivate plugins
>> if they are not in use for some period of time? Or may be I'm wrong?
>>
>> Sergiy
|
|
|
| Re: lazy deinitialization [message #248819 is a reply to message #248236] |
Thu, 03 June 2004 13:36 |
| Eclipse User |
|
|
|
Originally posted by: sergiy.dubovik.leiki.fi
Kevin wrote:
> Pascal is correct for the most part. I believe it could be possible to a
> degree. Within a classloader of a plugin you could keep track of all classes
> found within the classpath of the plugin and set a marker of what time it
> was accessed. Have a separate thread check all the plugins at periodic
> rates, checking this value. The problem is, this value would only be updated
> when a class is first looked for. There is no telling what plugins may be
> doing with the class after it's found. I don't know for sure, but pretty
> sure once the JVM has found a class, it has it's own internal map or cache
> of the class:classloader so that it no longer asks the classloader to find a
> class. I am really not sure if there is a way to crack in to the JVM's
> internals to "watch" class activity or not, especially without some sort of
> degradation of performance.
I think it's too much. Tracking several thousands of classes may destroy
the purpose of such a feature. As wrote to Pascal, platform should ask
plugin if it can be removed. This simplifies things a lot.
> If a plugin used it's own classes and that was it, and no other plugin used
> those classes, it could be possible for a plugin to deactivate itself after
> some time in some manner. But this is not the case, so like Pascal said, I
> think it's pretty impossible to be able to deactivate a plugin unless you
> find some way to watch all class activity for a plugin's classes, including
> new instances of it or anything the GC may reclaim... destruction of a class
> instance. Maybe an AOP framework can do this...not sure?
>
> Still, like Pascal said, what happens to GUI based plugins. If they
> deactivate, their GUI usually would go away. Maybe if they build upon an
> actionSet their menuitem stays, so that when its clicked on it re-activates
> the plugin. But I don't see how this would be possible otherwise.
Sorry, I don't see what's the problem with GUI. When you start Eclipse
GUI plugin
is not loaded. What's the problem with unloading it? If you have open UI
Editor which is not in used for several hours, plugin can ask user "I
will be unloaded all data will be save, do you want to proceed?"
Probably the better idea will be to have Plugin Activity view, which
will show unused plugins with a button to unload them.
Sergiy
|
|
|
| Re: lazy deinitialization [message #249157 is a reply to message #248070] |
Thu, 03 June 2004 21:55 |
| Eclipse User |
|
|
|
Originally posted by: sergiy.dubovik.leiki.fi
>> The question is why there is no feature which will deactivate plugins
>> if they are not in use for some period of time? Or may be I'm wrong?
>
>
> Since 3.0 it is possible to unload plugins dynamically during runtime of
> Eclipse. But don't ask me for code, I'm currently also searching for how
> to do that programmatically. In my RCP application I'd like to unload
> the help system plugins after the user closed the help browser.
Isn't it available only for OSGi plugins?
Sergiy
|
|
|
Goto Forum:
Current Time: Sun Dec 22 04:04:29 GMT 2024
Powered by FUDForum. Page generated in 0.05513 seconds |
] 
Search
Help
Register
Login
Home
