Skip to content

Commit 30ccede

Browse files
committed
Update memory management information.
1 parent 201aecd commit 30ccede

File tree

1 file changed

+8
-6
lines changed

1 file changed

+8
-6
lines changed

architecture.html

Lines changed: 8 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,7 @@ <h2><a id="memory">Memory Management</a></h2>
4040
<p>The master object is the Profile object. Each Profile object is
4141
responsible for managing the memory of its child objects which are C
4242
structures. When the Profile object goes out of scope, it recursively
43-
frees all its objects.&nbsp; In the class diagram, this can bee seen
43+
frees all its objects. In the class diagram, this can bee seen
4444
via the composition relationships. The owning object is denoted with a
4545
filled in black diamond. Thus a Profile frees its threads, Threads
4646
free their CallTrees and Methods, etc.</p>
@@ -50,11 +50,13 @@ <h2><a id="memory">Memory Management</a></h2>
5050
done via the GC mark phase. CallTree instances mark their associated MethodInfo instances, and MethodInfo
5151
instances in turn mark their owning Profile instance.
5252
</p>
53-
<p>Previous versions of RubyProf (before 1.3) would not keep the top level Profile instance alive and instead
54-
would detect when the underlying Ruby object was freed. However, this approach could result in
55-
crashes if a GC happened just at the wrong time. Specifically, when trying to expose an object such as
56-
a CallTree Ruby performs a memory allocation. This allocation could trigger a GC, freeing the top level
57-
Profile instance and its associated CallTree. Thus the returned CallTree instance would be invalid.
53+
<p>Starting with version 1.5 it is possible to create new instances of the
54+
Thread, CallTree and MethodInfo classes from Ruby. In general you won't need to use this
55+
functionality - it was added to make it easier to write tests. However, this functionality does
56+
complicate memory management because some objects are now owned by the C extension while others are
57+
owned by Ruby. To track this information an internal ownership flag was added to instances of these classes.
58+
RubyProf automatically handles this, but it is important to understand if you are reading or
59+
modifying the C code.</p>
5860
</p>
5961
</div>
6062
</div>

0 commit comments

Comments
 (0)