A Weak Pharo Story Video: https://youtu.be/nLEmAVVC6aQ Thu, August 25, 3:00pm – 3:15pm Description Automatic garbage collection, used to free unused objects, generally provides a finalization mechanism that allows developers to execute some arbitrary code when an object was or is about to be garbage collected. This finalization mechanism, useful to free external resources, is implemented in Pharo through the usage of special weak references and a weak registry. While this finalization process was in place and working since several years, with the increase of the complexity of the Pharo IDE it demonstrated to not be sufficient. In this talk we will show some popular misconceptions of the idea of "weak" references, and how memory leaks can be (and were) created from these misconceptions. We will also show how to avoid and solve this problem, ending up in the introduction of Ephemerons in latest Pharo 6. Bio: Guille Polito is research engineer at CNRS, France. Pharoer since 2010, he participates actively in the Pharo open source community since several years. He currently works on the modularization of Pharo where he does software archeology, refactoring, library rewriting and participates in the Virtual Machine development.

1. Weak Pharo
Story
Pavel Krivanek & Guille Polito
A

2. Smalltalk is a
GC'ed
language

3. Two kind of leaks
● Leak application objects
e.g., your domain objects, collections...
● Leak external objects
e.g., sockets, files, memory allocated
in C heap

4. Root objects hold yours!
These two
guys in the
red area are
never going to
be collected

5. But... we have Weak References

6. Weak References In One Slide
Not
Collected

7. Weak References In One Slide
Not
Collected

8. What about external objects?
File id
Who closes the
file if it gets
collected?

9. Finalization
There is a registry of
“Objects to be notified when about to be
collected”
WeakRegistry default add: theInterestedGuy

10. Object Finalization
File id
The registry
notifies
finalize
close

11. But NONE of it is

12. [ WARNING]
The following images can
affect sensitive people

13. No matter how weak
your references are
Memory Leaks
will find you

14. The Weak Pharo Story (finally)
Once upon a time, there was
Announcements, an event delivery library,
that the princess named Engineer used to
notify myObject from anEvent
announcer
when: anEvent
send: #message
to: myObject

15. The Weak Pharo Story (II)
But Engineer did love myObject so much
that it did not want to retain it for ever. It did
not want announcer to hold myObject
strongly. She wanted a weak announcer.
announcer weak
when: anEvent
send: #message
to: myObject

16. The Weak Pharo Story (III)
However, Engineer did not know this may
curse myObject to be alive for the eternity.
And never be collected and see his friends
die. And create OutOfMemory errors on the
land of objects to torment the rest of the
objects.
The end

17. Case 1: The Strong Announcer

18. Case 1: The Strong Announcer

19. Case 2: The Weak Announcer

20. Case 2: The Weak Announcer

21. Case 3: The Hybrid Announcer

22. Case 3: The Hybrid Announcer

23. Case 3: The Hybrid Announcer

24. Autopsy
● Weak references do not simply avoid leaks!
● Finalization itself can create leaks!

25. So... solutions?
1) How do we detect leaks?
2) How do we prevent some?

26. #1 ­ Detecting Leaks

27. Memory leaks investigation
Why ???

28. anObject pointersTo
● Very inefficient
SystemNavigation default allObjectsDo: [:e |
(e pointsTo: self) ifTrue: [
pointers add: e ]].

29. Easy to get lost
anObject pointersTo first
pointersTo first pointersTo
second pointersTo last...

30. Open pointers to...
● Easy to use for simple cases
● Uses #pointersTo
● References from tools more mess▶

31. Hell of announcements and
weak references

32. RefsHunter
● Temporary snapshot of the object memory

33. RefsHunter
● Shows the shortest path from one object to
another
● Fast queries
rh := RefsHunter snapshot.
rh wayFrom: (Array>>#asArray)
to: Smalltalk specialObjectsArray.

34. RefsHunter
● Find references path to global space
● Easy to use
● No GUI
● Memory inefficent
– more snapshots are not a good idea, really
● Download from the Catalog

36. Avoid memory leaks
● Memory leak tests
– Time consuming for basic Pharo image

37. #2 – Avoiding Leaks
● Ephemerons are special objects used for finalization
● They do not create leaks by themselves
(as the WeakRegistry did)
● Soon in Pharo 6.0
Ephemeron Finalization

38. Ephemerons in Case 3
Ephemeron!
Ephemeron Registry!

39. Lessons learned
● Announcements are sometimes overused
● Crazy leaking objects in the image
– some tools opened in past during manual
integration referenced by active hand click
state
● Not every leak lasts forever
– it takes 30 seconds to garbage collect closed
Nautilus
● We need better tools

40. The End
● Weak references are nice
● But they are not magical
You can still create memory leaks with them
● Ephemerons will fix it partially
But you still need to know what you're doing a bit...

41. Ephemerons – Operational View
● When the GC passes...
● 1) It does not traverse ephemerons:
It queues them
● 2) Then
[ traverses ephemerons whose key is referenced ]
whileTrue: [
there are ephemerons with keys referenced ]

42. Exercises:
key
value
ephemeron