disposing swing models

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

disposing swing models

Holger
Hi,

here at work I'm doing some memory profiling.

I think, that EventListModel.dispose and EventTableModel.dispose are incomplete.

Both models register themselves as list event listener on the SwingTreadProxyList.
But they don't remove the listener in dispose.
So they stay as dependent listener in the ListEventPublisher of the source list.

Can you confirm this?

Thanks,
Holger


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: disposing swing models

Holger
Hi,

... and AutoCompleteSupport.uninstall should probably dispose the
AutoCompleteComboBoxModel after use.

Just some observations,
Holger

> Hi,
>
> here at work I'm doing some memory profiling.
>
> I think, that EventListModel.dispose and EventTableModel.dispose are incomplete.
>
> Both models register themselves as list event listener on the SwingTreadProxyList.
> But they don't remove the listener in dispose.
> So they stay as dependent listener in the ListEventPublisher of the source list.
>
> Can you confirm this?
>
> Thanks,
> Holger
>
>
> ______________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: disposing swing models

Jesse Wilson
Looks like you've found some serious bugs!
Generally I imagine users would have at minimum
a SortedList before the EventTableModel that
would also be disposed, so hopefully this bug isn't
hurting people badly in the wild.

I've created a defect in our issues tracker,
  https://glazedlists.dev.java.net/issues/show_bug.cgi?id=350

If you'd like to tackle this Holger, please do. Otherwise
I'll take it on sometime later this week.

Cheers,
Jesse


On 7/18/06, Holger Brands <[hidden email]> wrote:

> Hi,
>
> ... and AutoCompleteSupport.uninstall should probably dispose the
> AutoCompleteComboBoxModel after use.
>
> Just some observations,
> Holger
>
> > Hi,
> >
> > here at work I'm doing some memory profiling.
> >
> > I think, that EventListModel.dispose and EventTableModel.dispose are incomplete.
> >
> > Both models register themselves as list event listener on the SwingTreadProxyList.
> > But they don't remove the listener in dispose.
> > So they stay as dependent listener in the ListEventPublisher of the source list.
> >
> > Can you confirm this?
> >
> > Thanks,
> > Holger
> >
> >
> > ______________________________________________________________
> > Verschicken Sie romantische, coole und witzige Bilder per SMS!
> > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ______________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: disposing swing models

James Lemieux
In reply to this post by Holger
You're absolutely right Holger. The ListEventPubilsher necessitates that we dispose all lists in the pipeline that are now defunct... not just the "lowest level list."

It's true that disposing the lowest level list is good enough to prevent ListEvents from trickling to EventLists "layered on top," but memory wise the ListEventPublisher would definitely leak the models that aren't implementing dispose properly.

Interestingly, I just completed a memory leak "sweep and fix" of our project at work. I stumbled onto a ridiculously awesome Java Profiler called YourKit. I can't recommend this tool highly enough. Read their "mission statement kind of thing" here http://yourkit.com/articles/index.jsp for an understanding of why it rules.

And here's the best things:

1) It integrates tightly with nearly all major IDEs on the market. Certainly Eclipse and Intellij (it is actually written by Intellij developers).

2) They grant free licenses to active open source developers, and Glazed Lists was recently accepted into this program! We should receive our licenses in a few days.

Good find Holger. If you're "in the thick of it" and you want to actually write the simple fixes and test that unregistering those listeners actually frees the memory (and there's not something ELSE keeping those models around) that would be great. Otherwise I can handle it soon enough.

James.

On 7/18/06, Holger Brands <[hidden email]> wrote:
Hi,

... and AutoCompleteSupport.uninstall should probably dispose the
AutoCompleteComboBoxModel after use.

Just some observations,
Holger

> Hi,
>
> here at work I'm doing some memory profiling.
>
> I think, that EventListModel.dispose and EventTableModel.dispose are incomplete.
>
> Both models register themselves as list event listener on the SwingTreadProxyList.
> But they don't remove the listener in dispose.
> So they stay as dependent listener in the ListEventPublisher of the source list.
>
> Can you confirm this?
>
> Thanks,
> Holger
>
>
> ______________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: disposing swing models

Holger
In reply to this post by Holger
Jesse,

I'll look into this and fix the issue.

Thanks,
Holger

> Looks like you've found some serious bugs!
> Generally I imagine users would have at minimum
> a SortedList before the EventTableModel that
> would also be disposed, so hopefully this bug isn't
> hurting people badly in the wild.
>
> I've created a defect in our issues tracker,
>   https://glazedlists.dev.java.net/issues/show_bug.cgi?id=350
>
> If you'd like to tackle this Holger, please do. Otherwise
> I'll take it on sometime later this week.
>
> Cheers,
> Jesse
>
>

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: disposing swing models

Holger
In reply to this post by Holger
James,

thanks for the feedback, I'm on it and will test the fix with our application.

BTW, great news concerning the profiler.
At work we use JProfiler, also a cool tool.

Thanks,
Holger

> You're absolutely right Holger. The ListEventPubilsher necessitates that we dispose all lists in the pipeline that are now defunct... not just the "lowest level list."
>
> It's true that disposing the lowest level list is good enough to prevent ListEvents from trickling to EventLists "layered on top," but memory wise the ListEventPublisher would definitely leak the models that aren't implementing dispose properly.
>
>
> Interestingly, I just completed a memory leak "sweep and fix" of our project at work. I stumbled onto a ridiculously awesome Java Profiler called YourKit. I can't recommend this tool highly enough. Read their "mission statement kind of thing" here http://yourkit.com/articles/index.jsp for an understanding of why it rules.
>
> And here's the best things:
>
> 1) It integrates tightly with nearly all major IDEs on the market. Certainly Eclipse and Intellij (it is actually written by Intellij developers).
>
>
> 2) They grant free licenses to active open source developers, and Glazed Lists was recently accepted into this program! We should receive our licenses in a few days.
>
> Good find Holger. If you're "in the thick of it" and you want to actually write the simple fixes and test that unregistering those listeners actually frees the memory (and there's not something ELSE keeping those models around) that would be great. Otherwise I can handle it soon enough.
>
>
> James.
>
>
> On 7/18/06, Holger Brands <[hidden email]> wrote:
> Hi,
>
> ... and AutoCompleteSupport.uninstall should probably dispose the
> AutoCompleteComboBoxModel after use.
>
> Just some observations,
> Holger
>
> > Hi,
> >
> > here at work I'm doing some memory profiling.
>
> >
> > I think, that EventListModel.dispose and EventTableModel.dispose are incomplete.
> >
> > Both models register themselves as list event listener on the SwingTreadProxyList.
> > But they don't remove the listener in dispose.
>
> > So they stay as dependent listener in the ListEventPublisher of the source list.
> >
> > Can you confirm this?
> >
> > Thanks,
> > Holger
> >
> >
> > ______________________________________________________________
>
> > Verschicken Sie romantische, coole und witzige Bilder per SMS!
> > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
> >
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
>
>
> ______________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt bei
> WEB.DE FreeMail: http://f.web.de/?mc=021193
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: disposing swing models

Holger
In reply to this post by Holger
Hey James,

I made the (trivial) fixes on
EventListModel
EventTableModel
EventTreeTableModel
AutoCompleteSupport

and will verify them when the next latest build is available.

But I've another question regarding EventTableModel/EventTreeTableModel:

The constructor looks like this:

...
if (source instanceof SwingThreadProxyEventList)
this.swingThreadSource = (SwingThreadProxyEventList<E>) source;
else
this.swingThreadSource = GlazedListsSwing.swingThreadProxyList(source);
...

In method dispose the swingThreadSource is always disposed.
Is this correct?
Or should it only be disposed, if it is created in the constructor?
I think it should not be disposed, if it is passed in as source list.

Thanks,
Holger

>You're absolutely right Holger. The ListEventPubilsher necessitates that we dispose all lists in the pipeline that are now defunct... not just the "lowest level list."
>
> It's true that disposing the lowest level list is good enough to prevent ListEvents from trickling to EventLists "layered on top," but memory wise the ListEventPublisher would definitely leak the models that aren't implementing dispose properly.
>
>
> Interestingly, I just completed a memory leak "sweep and fix" of our project at work. I stumbled onto a ridiculously awesome Java Profiler called YourKit. I can't recommend this tool highly enough. Read their "mission statement kind of thing" here http://yourkit.com/articles/index.jsp for an understanding of why it rules.
>
> And here's the best things:
>
> 1) It integrates tightly with nearly all major IDEs on the market. Certainly Eclipse and Intellij (it is actually written by Intellij developers).
>
>
> 2) They grant free licenses to active open source developers, and Glazed Lists was recently accepted into this program! We should receive our licenses in a few days.
>
> Good find Holger. If you're "in the thick of it" and you want to actually write the simple fixes and test that unregistering those listeners actually frees the memory (and there's not something ELSE keeping those models around) that would be great. Otherwise I can handle it soon enough.
>
>
> James.
>
>
> On 7/18/06, Holger Brands <[hidden email]> wrote:
> Hi,
>
> ... and AutoCompleteSupport.uninstall should probably dispose the
> AutoCompleteComboBoxModel after use.
>
> Just some observations,
> Holger
>
> > Hi,
> >
> > here at work I'm doing some memory profiling.
>
> >
> > I think, that EventListModel.dispose and EventTableModel.dispose are incomplete.
> >
> > Both models register themselves as list event listener on the SwingTreadProxyList.
> > But they don't remove the listener in dispose.
>
> > So they stay as dependent listener in the ListEventPublisher of the source list.
> >
> > Can you confirm this?
> >
> > Thanks,
> > Holger
> >
> >
> > ______________________________________________________________
>
> > Verschicken Sie romantische, coole und witzige Bilder per SMS!
> > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
> >
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
>
>
> ______________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt bei
> WEB.DE FreeMail: http://f.web.de/?mc=021193
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: disposing swing models

James Lemieux
Holger,

   Yeah, you're right. I changed the code only two days ago to conditionally build the SwingThreadProxyEventList if the source is not one already. Before that, the constructor always built one, and the dispose() method was correct. Now I've ruined it!

   Conditionally building the STPEL was introduced because it would be nice if EventTreeTableModel could delegate its TableModel methods to an internal EventTableModel and then provide implementations of just the methods defined by TreeTableModel. Ideally in that case, you want to avoid creating more than one STPEL (one in the EventTreeTableModel constructor and one in the EventTableModel constructor) since it is unnecessary and wasteful.

    I considered allowing EventTreeTableModel to extend EventTableModel, but voted against it so that the public APIs of the two may evolve independently if need be.

Nice catch. I'll fix that tomorrow along with some test cases.

James

On 7/20/06, Holger Brands <[hidden email]> wrote:
Hey James,

I made the (trivial) fixes on
EventListModel
EventTableModel
EventTreeTableModel
AutoCompleteSupport

and will verify them when the next latest build is available.

But I've another question regarding EventTableModel/EventTreeTableModel:

The constructor looks like this:

...
if (source instanceof SwingThreadProxyEventList)
this.swingThreadSource = (SwingThreadProxyEventList<E>) source;
else
this.swingThreadSource = GlazedListsSwing.swingThreadProxyList (source);
...

In method dispose the swingThreadSource is always disposed.
Is this correct?
Or should it only be disposed, if it is created in the constructor?
I think it should not be disposed, if it is passed in as source list.

Thanks,
Holger

>You're absolutely right Holger. The ListEventPubilsher necessitates that we dispose all lists in the pipeline that are now defunct... not just the "lowest level list."
>
> It's true that disposing the lowest level list is good enough to prevent ListEvents from trickling to EventLists "layered on top," but memory wise the ListEventPublisher would definitely leak the models that aren't implementing dispose properly.
>
>
> Interestingly, I just completed a memory leak "sweep and fix" of our project at work. I stumbled onto a ridiculously awesome Java Profiler called YourKit. I can't recommend this tool highly enough. Read their "mission statement kind of thing" here http://yourkit.com/articles/index.jsp for an understanding of why it rules.
>
> And here's the best things:
>
> 1) It integrates tightly with nearly all major IDEs on the market. Certainly Eclipse and Intellij (it is actually written by Intellij developers).
>
>
> 2) They grant free licenses to active open source developers, and Glazed Lists was recently accepted into this program! We should receive our licenses in a few days.
>
> Good find Holger. If you're "in the thick of it" and you want to actually write the simple fixes and test that unregistering those listeners actually frees the memory (and there's not something ELSE keeping those models around) that would be great. Otherwise I can handle it soon enough.
>
>
> James.
>
>
> On 7/18/06, Holger Brands <[hidden email]> wrote:
> Hi,
>
> ... and AutoCompleteSupport.uninstall should probably dispose the
> AutoCompleteComboBoxModel after use.
>
> Just some observations,
> Holger
>
> > Hi,
> >
> > here at work I'm doing some memory profiling.
>
> >
> > I think, that EventListModel.dispose and EventTableModel.dispose are incomplete.

> >
> > Both models register themselves as list event listener on the SwingTreadProxyList.
> > But they don't remove the listener in dispose.
>
> > So they stay as dependent listener in the ListEventPublisher of the source list.
> >
> > Can you confirm this?
> >
> > Thanks,
> > Holger
> >
> >

> > ______________________________________________________________
>
> > Verschicken Sie romantische, coole und witzige Bilder per SMS!
> > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
> >
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
>
>
> ______________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt bei
> WEB.DE FreeMail: http://f.web.de/?mc=021193
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]