Today I spent almost all the day trying to build some samples with both the conservative Boehm and the Electrical Fire's generational garbage collectors. With the first, which is conservative and uses a mark and sweep algorithm, I could do a small example and looks easy to use. With the second (the one from the Electrical fire project) I couldn't build it, because of the old and bad Make files (it looks like they are not updated).
However, the papers I've found on google don't satisfy me, and I'm thinking I should buy a book about GC written by Richard Jones. So, if you want to contribute, you can give $ 0.1 and with 800 person helping me I will be able to buy that book ;-).
lunes, julio 19, 2004
viernes, julio 16, 2004
Avoiding showing errors is bad
I have just finished installing Fedora Core 2 and well, just running some problems (ntfs support, usb ports, etc). But the biggest problem is that I still can't run the graphical mode, adn worse, I don't get error messages.
In some manner, it is normal in software to have some problems. But, what about showing good errors? In my opinion, good error messages can really help to know where the error is. Bad error messages can help, but maybe they won't give you enough information. Finally, if you are only giving some messages to some errors, well, then the problems for the user will be wrong.
Finally, I would like to say that I've been receiving a huge amount of critics. It used to be good when I only receive critics (and most importan, constructives ones) when asked for them. But, what about when you receive them without asking for them? And the worst of all, it's when you got critics about things that all the persons do every minute. Advantes of living in an exotic country like Mexico is.
In some manner, it is normal in software to have some problems. But, what about showing good errors? In my opinion, good error messages can really help to know where the error is. Bad error messages can help, but maybe they won't give you enough information. Finally, if you are only giving some messages to some errors, well, then the problems for the user will be wrong.
Finally, I would like to say that I've been receiving a huge amount of critics. It used to be good when I only receive critics (and most importan, constructives ones) when asked for them. But, what about when you receive them without asking for them? And the worst of all, it's when you got critics about things that all the persons do every minute. Advantes of living in an exotic country like Mexico is.
jueves, julio 08, 2004
Garbage Collection in the .Net Framework
Some time ago I was reading some papers about Garbage Collection, which is the process of managing the allocations and deallocations of memory in an environment. Unfortunately, that information is hard to find in the web, since only some little info or slides are avalaible (I found an interesting book at amazon about GC, but it is so expensive).
Since that, I'm trying to read that little info, and since I could access the ACM digital library, I'm going to check some related papers. However, I have the experience that this kind of papers only cover the theorical part, and thus are not enough for me (I have more than a just theorical interest on GC).
However, I found good papers in the MSDN site and currently I'm reading the GC internal. Those papers are interesant, but again, they do not cover the area I'm interesting in (of course that I'm interested in the area they cover, it is just that I need some more information).
Something very interesant is a process called Resurrection, by which a dead object (unreachable and thus marked for being deleted from the memory) can be resurrected. Imagine you have an object that has a Finalizer method (destructor syntaxis in C#) that assigns a global/static variable a pointer to your current object:
~MyClass ()
{
// 'this' refers to the current instance
MyNamespace.AnyClass.AnStaticObject = this;
}
When and object has a Finalizer (destructor in C#), is added to an internal GC data structure called F-Reachable queue, that contains pointers to object that need to be finalized before they get deleted. However, if you have something like the previous code, your object will live again, but its Finalize method won't be called when it becomes -again- unreachable.
In fact, resurrection should NEVER happen. Just for the purpose of 'security', if the object needs to be finalized, an internal boolean flag could be added, keeping the state (finalized or not) and throw an expection when a method is called (throwing an expeption from the Finalizer would only finish the method).
Since that, I'm trying to read that little info, and since I could access the ACM digital library, I'm going to check some related papers. However, I have the experience that this kind of papers only cover the theorical part, and thus are not enough for me (I have more than a just theorical interest on GC).
However, I found good papers in the MSDN site and currently I'm reading the GC internal. Those papers are interesant, but again, they do not cover the area I'm interesting in (of course that I'm interested in the area they cover, it is just that I need some more information).
Something very interesant is a process called Resurrection, by which a dead object (unreachable and thus marked for being deleted from the memory) can be resurrected. Imagine you have an object that has a Finalizer method (destructor syntaxis in C#) that assigns a global/static variable a pointer to your current object:
~MyClass ()
{
// 'this' refers to the current instance
MyNamespace.AnyClass.AnStaticObject = this;
}
When and object has a Finalizer (destructor in C#), is added to an internal GC data structure called F-Reachable queue, that contains pointers to object that need to be finalized before they get deleted. However, if you have something like the previous code, your object will live again, but its Finalize method won't be called when it becomes -again- unreachable.
In fact, resurrection should NEVER happen. Just for the purpose of 'security', if the object needs to be finalized, an internal boolean flag could be added, keeping the state (finalized or not) and throw an expection when a method is called (throwing an expeption from the Finalizer would only finish the method).
Suscribirse a:
Entradas (Atom)