<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: [.NET Internals 06] Generational garbage collection	</title>
	<atom:link href="https://www.codejourney.net/net-internals-06-generational-garbage-collection/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.codejourney.net/net-internals-06-generational-garbage-collection/</link>
	<description>Become a better .NET full stack web developer</description>
	<lastBuildDate>Sat, 17 Nov 2018 12:11:29 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9</generator>
	<item>
		<title>
		By: Konrad Kokosa		</title>
		<link>https://www.codejourney.net/net-internals-06-generational-garbage-collection/#comment-139</link>

		<dc:creator><![CDATA[Konrad Kokosa]]></dc:creator>
		<pubDate>Fri, 31 Aug 2018 03:52:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.dsibinski.pl/?p=2741#comment-139</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.codejourney.net/net-internals-06-generational-garbage-collection/#comment-138&quot;&gt;Dawid Sibiński&lt;/a&gt;.

My pleasure! I look forward to the review of the book ;)]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.codejourney.net/net-internals-06-generational-garbage-collection/#comment-138">Dawid Sibiński</a>.</p>
<p>My pleasure! I look forward to the review of the book 😉</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Dawid Sibiński		</title>
		<link>https://www.codejourney.net/net-internals-06-generational-garbage-collection/#comment-138</link>

		<dc:creator><![CDATA[Dawid Sibiński]]></dc:creator>
		<pubDate>Thu, 30 Aug 2018 19:26:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.dsibinski.pl/?p=2741#comment-138</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.codejourney.net/net-internals-06-generational-garbage-collection/#comment-136&quot;&gt;Konrad Kokosa&lt;/a&gt;.

Thank you for your valuable comment Konrad :)
I modified the article a bit in these misleading places according to your remarks.
Looking forward to your book assuming you dig into these details that deeply ;)

Cheers!
Dawid]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.codejourney.net/net-internals-06-generational-garbage-collection/#comment-136">Konrad Kokosa</a>.</p>
<p>Thank you for your valuable comment Konrad 🙂<br />
I modified the article a bit in these misleading places according to your remarks.<br />
Looking forward to your book assuming you dig into these details that deeply 😉</p>
<p>Cheers!<br />
Dawid</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Konrad Kokosa		</title>
		<link>https://www.codejourney.net/net-internals-06-generational-garbage-collection/#comment-136</link>

		<dc:creator><![CDATA[Konrad Kokosa]]></dc:creator>
		<pubDate>Wed, 29 Aug 2018 13:54:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.dsibinski.pl/?p=2741#comment-136</guid>

					<description><![CDATA[Yet again nice article! A few remarks:

&lt;em&gt;&quot;after the full GC cycle generation 0 and generation 1 become empty&quot;&lt;/em&gt;

Nope. During full GC objects from gen0 are promoted to gen1 so it does not have to be empty.

&lt;em&gt;&quot;normally using static data should be avoided as much as possible and reasonable&quot;&lt;/em&gt;

Long living objects in gen2 (like statics) are not a problem by itself. Just by the fact that they are there does not mean full GCs will be triggered. The main problem are objects that are living just long enough to be promoted to gen2 (possibly triggering full GC) and die there soon (putting the work on the GC)

&lt;em&gt;&quot;card table stores this information per “bit”, which represents 128 bytes of managed memory&quot;&lt;/em&gt;

128 bytes in 32-bit, 256 bytes in 64-bit. And due to write barrier optimization, no single bit is manipulated but the entire byte. So, in fact making such older-to-younger reference marks 2048 bytes as potential roots region.]]></description>
			<content:encoded><![CDATA[<p>Yet again nice article! A few remarks:</p>
<p><em>&#8220;after the full GC cycle generation 0 and generation 1 become empty&#8221;</em></p>
<p>Nope. During full GC objects from gen0 are promoted to gen1 so it does not have to be empty.</p>
<p><em>&#8220;normally using static data should be avoided as much as possible and reasonable&#8221;</em></p>
<p>Long living objects in gen2 (like statics) are not a problem by itself. Just by the fact that they are there does not mean full GCs will be triggered. The main problem are objects that are living just long enough to be promoted to gen2 (possibly triggering full GC) and die there soon (putting the work on the GC)</p>
<p><em>&#8220;card table stores this information per “bit”, which represents 128 bytes of managed memory&#8221;</em></p>
<p>128 bytes in 32-bit, 256 bytes in 64-bit. And due to write barrier optimization, no single bit is manipulated but the entire byte. So, in fact making such older-to-younger reference marks 2048 bytes as potential roots region.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
