Abstract
Previous chapters describe the automatic memory management process in .NET quite comprehensively. Chapter 6 contains information about how objects are created, while chapters from 7 to 11 inform in detail how they are collected when no longer needed. However, there are some side mechanisms, without the description of which our knowledge would not be complete. In this chapter we will focus on three such mechanisms. Although they exist separately and can be used independently, they relate to each other conceptually. All of them concern a common topic - the lifetime of the object.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
In the case of Linux resources, they are commonly represented as regular integers.
- 2.
Even worse, due to resurrection and possible timing, there may be multiple simultaneous calls to the same finalizer.
- 3.
Refer to the early root collection technique described in Chapter 8.
- 4.
Literature calls it “finalizer reachable,” but the mentioned name better aligns with the .NET naming.
- 5.
For simplicity it happens on each iteration although we could call it, for example, periodically. Such a little contrived example allows us to better illustrate some diagnostic problems.
- 6.
There is an issue https://github.com/Microsoft/perfview/issues/722 created to fix that, so you can track it whether it has been already fixed at the time of your reading.
- 7.
As explained earlier, suppressing finalization logic is trivial, based only on setting a single bit in an object header. Thus, we should not be afraid of its overhead (for example, by calling it twice on the same object both from the derived as well as from the base class).
- 8.
They are introduced to provide a standardized way of consuming handles as most often indeed those values are treated as invalid handles.
- 9.
We are on thin ice here, depending on deep implementation details how objects get promoted. For example, with the current implementation, if the target object is pinned (or becomes a part of extended pinned plug), it may be demoted and we will be calling our callback again for ephemeral GCs also.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2018 Konrad Kokosa
About this chapter
Cite this chapter
Kokosa, K. (2018). Object Lifetime. In: Pro .NET Memory Management. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-4027-4_12
Download citation
DOI: https://doi.org/10.1007/978-1-4842-4027-4_12
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-4026-7
Online ISBN: 978-1-4842-4027-4
eBook Packages: Professional and Applied ComputingApress Access BooksProfessional and Applied Computing (R0)