Tim - actually strong references _can_cause memory leaks. would you consider
either of the following lines bad coding?

 

Application.application.addEventListener(Event.ENTER_FRAME, onEnterFrame);

 

Application.application.addEventListener(Event.ENTER_FRAME, onEnterFrame,
false, 0, true);

 

Depends on the context you say? Partially. the big issue is the AVM2 memory
allocation/release cycle of which only a portion is published.  It is well
known that the Flash Player uses a 'greedy' memory allocation model with a
sometimes 'lazy' garbage collection. so, I beg to differ with your inference
that poor system performance is a result of "bad coding and lack of
understanding of components" when it is more a product of 'things unknown'
that necessitates  experimentation to find a performance balance. Jun Heider
did a fantastic presentation on this very issue at 360|Flex in Atlanta.

 

Essentially. The Flash Player garbage collectZOR will either use deferred
reference counting or mark and sweep (or perhaps both) to find things that
need cleaning up. If you have used a *strong* reference on an Object it will
be passed over until its reference count = 0. *Weak* references are not
included in a deferred reference cycle (since they probably don't have any
references and would always be marked for collection). This is where things
get juicy.

 

Mark and sweep traverses the application space to 'mark' any Objects that
are not reachable via some sort of parent-child relationship. Even if you
are cleaning up after yourself you may find that the Flash Player is
aggressively holding onto memory. which is what it was designed to do (see
greedy above). So. some memory problems may be averteted - while others will
be/are a burden you will need to deal with. 



Rick Winscot

 

 

 

 

From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Tim Rowe
Sent: Tuesday, July 15, 2008 1:17 AM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] When not to use weak references?

 

Strong references don't cause memory leaks, bad coding and lack of
understanding of components causes memory leaks.  This seems to be a topic a
lot like pointers all over again 30 years later, WRT how many people
understand them (or don't).

 

I actually agree you'd normally want a strong reference with a timer, if
it's going to continue to live.  Admittedly in that area I'm only
regurgitating what I've told (by many) and understood, as I've not yet had
to implement any timer code (or much in Flex at all) - but this is a topic
I'm keen to try to get right and understand from the start before I get too
deep in to things.  On timers and singletons there's something going on
there that I haven't quite done enough research into, but in what research I
have done I I can't seem to find much that says a strong reference should be
used on these kinds of objects.  Like I said, feel free to correct me on
anything here.

 

Personally I'd be happy to just do away with garbage collection altogether -
that would 'solve' the problem ;)

 

I must admit I'm finding a lot of anti-patterns and bad
implementations/ideas in the Flex world so far.

 

--Tim Rowe

  _____  

From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Daniel Gold
Sent: Tuesday, 15 July 2008 2:58 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] When not to use weak references?

 

I would agree that's not a best practice for writing timer code, just the
quickest example I could think of. When people read about how bad strong
references are and how they cause memory leaks, they tend to make EVERYTHING
weak which can lead to some nasty problems. Since you can't control the
timing or depend on garbage collection, 95% of the time the listener could
get called, the other 5% the target object could be GCd before the listener
ever runs. 

On Mon, Jul 14, 2008 at 11:49 PM, Josh McDonald <[EMAIL PROTECTED]> wrote:

Why use weak references on singletons or things that are going to live the
life of the application? Not saying it's wrong, just interested in the
logic.

The timer code above is a great example of when you need a strong reference,
but a nasty example of how to use a timer! I *really* don't like the idea of
the Timer instance only being available within the event handlers :)

A listener will always get called if the object it's listening to is still
around though right? Weak reference or no?

-Josh

 

On Tue, Jul 15, 2008 at 2:43 PM, Tim Rowe <[EMAIL PROTECTED]> wrote:

Use strong references when you're adding an event listener to the same
instance dispatching an event.  If it's an anonymous function, you need to
use a strong reference.  Also, use strong references when you want speed -
weak references are slower.

Always use weak references when dealing with singletons (Cairngorm's event
dispatcher is a singleton, hence, always use with Cairngorm), or objects
that live the life of the application.  This includes timers waiting on call
backs also.

 

Not always true but if you have an object you intend to never have
destroyed, but it may also be perfectly safe to use strong references.  Keep
in mind though that using a weak reference on, say, an event listener where
a strong one was required may result in things like that listener not
getting called.

 

I'm only new to Flex, but this is as I understand it, and no doubt I've
missed a few things here and there.

 

--Tim Rowe

  _____  

From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Boon Chew
Sent: Tuesday, 15 July 2008 2:08 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] When not to use weak references?

 


Hi all,

I have read posts that preached the goodness of weak references for event
listening, but have not read anything that suggests when you should use
strong reference over the weak one, and  the down side to using weak
references.

Any ideas when being weak is not bad thing? :)

- boon

 





-- 
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

:: Josh 'G-Funk' McDonald
:: 0437 221 380 :: [EMAIL PROTECTED] 

 

 

Reply via email to