Thursday 22 April 2010

Safe memory usage in C# part 1/2 - followup

Part of the reason I decided to split "Safe memory usage in C#" into two parts was simply that the entire article would be very large for a post.

The other, perhaps most important part, was to gauge people's reactions and comments.  When an explanation fails to meet a reader's needs, he will not be able to understand the discussed topic.  Some people react with polite inquiry, some will suggest superficially similar solutions that they do understand, while others take a more aggressive stance by stating that the topic is stupid anyway.

Judging from the blog post comments and the Reddit comments, I see that there are some points that require more detail.  I humbly apologize that I could not be clear enough in the initial post, but hopefully I will learn from this and write clearer posts in the future. :)  So, to answer your inquires:

Object pools are not used to prevent out of memory errors. - This is correct, but not sequitur.  The Linear Memory is also not an object pool.  It is a pre-allocated sequential memory pool.

Your 'safe memory usage' is not safe at all, for the love of Christ. - I can't really argue against this, as it is an emotionally laden religious argument.  If you can elaborate a bit on the technicals of why you believe it is not safe, I shall be happy to explain further.

You'll hit OOM when you deserialize them, and much sooner. - My very simplified Hello World introductory example is probably to blame for this one.  The objects should not be "serialized" and "deserialized", they should be created, manipulated, and used entirely within the LinearMemory.  You will be happy to know that the more advanced examples I have lined up for part two does exactly that!

There exists a rather advanced technique for really reserving memory [...] CriticalFinalizerObject - Good point!  I can see how this class comes to mind after reading "safe shutdown" in the first part of the introductory paragraph.  While it is sufficient for many purposes, the major drawbacks are that while the CFO solves the "safe shutdown" problem, its memory usage is not as controlled, and you cannot create such objects when you have run out of memory.

It is also possible to make a very limited use of pointers in unsafe context - Also a good point.  Though I strongly suggest against dabbling in an unsafe context - for obvious reasons!

Showing only the first [...] part of the [...] post adds insult to injury. I am sorry that you took this as an insult.  Hopefully, after reading this post, you will understand my motivations.

If you wanted C, why didn't you just use C? - I don't want C - it is neither platform-independent, type safe, or has a good standard library and vibrant community.  I want only to emulate parts of its more redeemable features in small, controlled parts of larger projects.

As soon as he implied that leaving a server running would cause out of memory errors in a completely different process, he demonstrated that he really doesn't understand virtual memory at all. - I always feel ill at ease responding to people who comment with the "smackdown" approach.  Not because the comment itself hurts my feelings or some such, but because if I point out errors in their post I make them look rather stupid in front of everyone.  That would make me feel bad, so that's why I politely decide to reply here instead of directly in the Reddit comments: You forget that virtual memory is still finite. That means one process can still use too much of available (virtual and physical) memory, leaving not enough for your process.

I hope that should make everyone happy. :)  If you have any more questions, please do not hesitate to use the comment field below.  I leave anonymous comments open specifically to encourage questions.

No comments:

Post a Comment