Re: GC has a barbaric destroyng model, I think
On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote: And I wouldn't say indiscriminately. Every function I marked with @trusted was checked by me so far. What did you check them for? :) Just first example: make and destruct, being marked as @trusted, don't prevent caller from UAF and double free vulnerabilities, and compiler can't help with that by checking the caller. Other functions marked as trusted have similar problems. If the the caller can't be automatically checked for safety and must ensure safety manually, it means the callee is @system.
Re: GC has a barbaric destroyng model, I think
On Friday, 13 February 2015 at 08:00:43 UTC, Kagamin wrote: On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote: And since today it is @safe wherever possible. Well, you marked functions @trusted rather indiscriminately :) Such approach doesn't really improve safety, and the code could work as well being @system. It's not like @system is inherently broken or something like that. Since with @safemarked functions are checked by the compiler it is advisable to mark functions with @safe. And I wouldn't say indiscriminately. Every function I marked with @trusted was checked by me so far. Of course I'm rather new to D, so I could be wrong. But since my other comrades aren't willing to use D, this code will rot on Github if nobody else will use it.
Re: GC has a barbaric destroyng model, I think
Yeah, since @trusted is checked manually, it's sort of a problem, if you don't know, how to check it.
Re: GC has a barbaric destroyng model, I think
On Friday, 13 February 2015 at 09:28:30 UTC, Kagamin wrote: On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote: And I wouldn't say indiscriminately. Every function I marked with @trusted was checked by me so far. What did you check them for? :) Just first example: make and destruct, being marked as @trusted, don't prevent caller from UAF and double free vulnerabilities, and compiler can't help with that by checking the caller. Other functions marked as trusted have similar problems. If the the caller can't be automatically checked for safety and must ensure safety manually, it means the callee is @system. That seems to be a problem with trusted and safe :)
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote: And since today it is @safe wherever possible. Well, you marked functions @trusted rather indiscriminately :) Such approach doesn't really improve safety, and the code could work as well being @system. It's not like @system is inherently broken or something like that.
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 11:10:34 +, ponce wrote: On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:04:27 +, ponce wrote: http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching i believe that yor work needs more official highlighting. maybe it worth having the links right on the front page of dlang.org Thanks :) but I'm not 100% sure about the correctness of it all. More like 80% :|. with big visibility people will fill your mailbox with reports, if any. ;- ) signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 08:55:43 UTC, Jonathan M Davis wrote: On Thursday, February 12, 2015 08:33:34 Kagamin via Digitalmars-d-learn wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. Really what it comes down to is that if you want deterministic destruction, you _don't_ use managed resources. You use malloc and free rather than new and the GC. Granted, that's way uglier than it should be right now, because the allocator stuff hasn't been finished yet, but it's really what's required if you want an object on the heap to have a deterministic lifetime. Memory that's managed by a GC just doesn't work that way. That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 08:14:49 UTC, Mike Parker wrote: On 2/12/2015 6:42 AM, ketmar wrote: this problem has very easy solition: we should stop calling class dtors destructors, and rename them to finalizers. Absolutely. So many people coming from C++ see destructor and want to use them as they did in C++. How often do we see people coming on here wondering why they can't get deterministic destruction out of class destructors? Of course, it's too late to change anything now, but we need a big, obvious link from the docs and the wiki and anywhere else people can read about destructors to a page that explains how D class destructors are not C++ class destructors. http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote: That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free. p.s. istream example is bad. what it does is simply highlighting the fact that there is no way to do deterministic management with GC. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote: That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free. and it can't be managed by GC too. that's why it has it's own crappy pseudo-gc implementation with refcounting. *and* it's memory managemet too, heh. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On 2/12/2015 6:09 PM, weaselcat wrote: On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. +1 don't complain about people wondering why class destructors don't work when there's no _real_ way to do it in D beyond 'drop down to C level and get going.' D is absolutely horrid for resource management. I'm not complaining. I'm simply suggesting that the very word destructor likely plays a role in the misconception that class destructors behave as they do in C++. However, I do think that when moving from one language to another, there has to be a certain expectation that things are going to be different and it shouldn't be a surprise when they are.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:04:27 +, ponce wrote: http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching i believe that yor work needs more official highlighting. maybe it worth having the links right on the front page of dlang.org Thanks :) but I'm not 100% sure about the correctness of it all. More like 80% :|.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker wrote: On 2/12/2015 6:09 PM, weaselcat wrote: On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. +1 don't complain about people wondering why class destructors don't work when there's no _real_ way to do it in D beyond 'drop down to C level and get going.' D is absolutely horrid for resource management. I'm not complaining. I'm simply suggesting that the very word destructor likely plays a role in the misconception that class destructors behave as they do in C++. However, I do think that when moving from one language to another, there has to be a certain expectation that things are going to be different and it shouldn't be a surprise when they are. What I think is that the GC should simply never call the destructors. The GC calling class destructors is currently a 50% solution that provide illusory correctness.
Re: GC has a barbaric destroyng model, I think
OK. there is some example:
// we're using an OpenGL
class A
{
protected int m_tex;
this()
{
// texture has been created in video memory. there is no GC
resource.
glGenTexture(1, m_tex);
glTexImage2D(); // texture in video memory
}
~this()
{
// release texture in video memory
glDeleteTextures(1, m_tex);
}
}
void foo()
{
// we do some operations...
A[] arrA = new A[1_000_000];
for (int i; iarr.length; i++)
arrA[i] = new A(); // generate texture
// do some operations... and return without explicit disposing
of arrA
}
main(...)
{
while(app.isNotExit)
{
foo();
}
}
if GC does not guarantee the calling of dtor we can't be sure
that some textures will be destroyed.
It will be followed by overflowing of the video memory.
And it is obvious, becouse we have no way to detect when the
objects are destroyed.
The video memory will leaks.
Re: GC has a barbaric destroyng model, I think
On Thursday, February 12, 2015 08:33:34 Kagamin via Digitalmars-d-learn wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. Really what it comes down to is that if you want deterministic destruction, you _don't_ use managed resources. You use malloc and free rather than new and the GC. Granted, that's way uglier than it should be right now, because the allocator stuff hasn't been finished yet, but it's really what's required if you want an object on the heap to have a deterministic lifetime. Memory that's managed by a GC just doesn't work that way. - Jonathan M Davis
Re: GC has a barbaric destroyng model, I think
On 2/12/2015 6:42 AM, ketmar wrote: this problem has very easy solition: we should stop calling class dtors destructors, and rename them to finalizers. Absolutely. So many people coming from C++ see destructor and want to use them as they did in C++. How often do we see people coming on here wondering why they can't get deterministic destruction out of class destructors? Of course, it's too late to change anything now, but we need a big, obvious link from the docs and the wiki and anywhere else people can read about destructors to a page that explains how D class destructors are not C++ class destructors.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. +1 don't complain about people wondering why class destructors don't work when there's no _real_ way to do it in D beyond 'drop down to C level and get going.' D is absolutely horrid for resource management.
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 09:04:27 +, ponce wrote: http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching i believe that yor work needs more official highlighting. maybe it worth having the links right on the front page of dlang.org signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
Truth be told, D has no guideline for deterministic destruction of managed resources.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote: sure. but when it comes, for example, for big data structures with complex cross-references, you'll inevitably found that you either leaking memory, or writing your own half-backed semi-working GC realization. ah, good luck doing effecient refcounting on slices, for example. and they aren't even remotely complex. Well. What is the trouble if dtors are always (it is garanteed) called by GC before their phisical destroying? It will help to avoid many awkward situations.
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 13:21:07 +, Paulo Pinto wrote: On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote: That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free. p.s. istream example is bad. what it does is simply highlighting the fact that there is no way to do deterministic management with GC. Other languages manage to do it with scopes (e.g. using/lambda expressions) and phantom/weak references. The only downsize it that it isn't as simple as a C++ destructor. but we have scopes and weak references in D too! i'm still enraged that i can't overload `new` and forced to use ugly `emplace!` and friends, but otherwise it's possible (albeit a little burdensome) to do refcounting for interfaces. what is bad is that programmer has to be *very* careful with that. even seasoned programmers can made some errors here, that's why reference counting should be as much compiler-controlled as it can be. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 13:55:20 +, Andrey Derzhavin wrote: On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote: sure. but when it comes, for example, for big data structures with complex cross-references, you'll inevitably found that you either leaking memory, or writing your own half-backed semi-working GC realization. ah, good luck doing effecient refcounting on slices, for example. and they aren't even remotely complex. Well. What is the trouble if dtors are always (it is garanteed) called by GC before their phisical destroying? It will help to avoid many awkward situations. that blocks various GC realizations or making 'em ineffective. yes, there is only one working GC realization for D now, but it doesn't mean that we can't have others in the future. even such seemingly simple task as calling dtor in the same thread where ctor was called is very difficult (how would you do that with concurrent GC, for example?). what to do with HUGE data structure, which is anchored in object with finalizer? (we now have ALOT of unused memory, yet still can't free it, as it is locked, waiting for finalizer call) and alot of other troubles. actually, it's not a GC weakness, it's a bug in programmer's way of thinking. just stop thinking that GC is simply a hidden free, that's not right. you can do manual resource management with `scope(exit)`, for example (just call `.close()` method or something), but you shouldn't expect that GC will (and should) do the same. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin wrote: If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts. Manual memory management should be possible in D, see for example https://github.com/Dgame/m3
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 12:10:21 +, Andrey Derzhavin wrote: if GC does not guarantee the calling of dtor we can't be sure that some textures will be destroyed. It will be followed by overflowing of the video memory. And it is obvious, becouse we have no way to detect when the objects are destroyed. The video memory will leaks. that is the way garbage collection works. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 12:52:02 +, Andrey Derzhavin wrote: If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts. sure. but when it comes, for example, for big data structures with complex cross-references, you'll inevitably found that you either leaking memory, or writing your own half-backed semi-working GC realization. ah, good luck doing effecient refcounting on slices, for example. and they aren't even remotely complex. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote: That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free. p.s. istream example is bad. what it does is simply highlighting the fact that there is no way to do deterministic management with GC. Other languages manage to do it with scopes (e.g. using/lambda expressions) and phantom/weak references. The only downsize it that it isn't as simple as a C++ destructor. -- Paulo
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 12:10:22 UTC, Andrey Derzhavin
wrote:
OK. there is some example:
// we're using an OpenGL
class A
{
protected int m_tex;
this()
{
// texture has been created in video memory. there is no GC
resource.
glGenTexture(1, m_tex);
glTexImage2D(); // texture in video memory
}
~this()
{
// release texture in video memory
glDeleteTextures(1, m_tex);
}
}
void foo()
{
// we do some operations...
A[] arrA = new A[1_000_000];
for (int i; iarr.length; i++)
arrA[i] = new A(); // generate texture
// do some operations... and return without explicit disposing
of arrA
}
main(...)
{
while(app.isNotExit)
{
foo();
}
}
if GC does not guarantee the calling of dtor we can't be sure
that some textures will be destroyed.
It will be followed by overflowing of the video memory.
And it is obvious, becouse we have no way to detect when the
objects are destroyed.
The video memory will leaks.
Exactly. That's why it's wrong to rely on the GC if you need
deterministic resource management. It's simply the wrong tool for
that.
Unfortunately, the right tools are a bit awkward to use, for
the time being. I still have hopes that we can finally get our
act together and get a usable `scope` implementation, which can
then be used to provide better library defined container types
as well as efficient reference counting.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 12:29:47 UTC, Marc Schütz wrote: Exactly. That's why it's wrong to rely on the GC if you need deterministic resource management. It's simply the wrong tool for that. Unfortunately, the right tools are a bit awkward to use, for the time being. I still have hopes that we can finally get our act together and get a usable `scope` implementation, which can then be used to provide better library defined container types as well as efficient reference counting. If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 11:11:53 UTC, ponce wrote: On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker wrote: On 2/12/2015 6:09 PM, weaselcat wrote: On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. +1 don't complain about people wondering why class destructors don't work when there's no _real_ way to do it in D beyond 'drop down to C level and get going.' D is absolutely horrid for resource management. I'm not complaining. I'm simply suggesting that the very word destructor likely plays a role in the misconception that class destructors behave as they do in C++. However, I do think that when moving from one language to another, there has to be a certain expectation that things are going to be different and it shouldn't be a surprise when they are. What I think is that the GC should simply never call the destructors. The GC calling class destructors is currently a 50% solution that provide illusory correctness. s/class destructors/any destructors/ It now calls struct destructors, too, IIRC, at least when the structs are in GC managed arrays.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 11:10:35 UTC, ponce wrote: On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:04:27 +, ponce wrote: http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching i believe that yor work needs more official highlighting. maybe it worth having the links right on the front page of dlang.org Thanks :) but I'm not 100% sure about the correctness of it all. More like 80% :|. You can put links in wiki: http://wiki.dlang.org/Articles
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 14:44:07 UTC, Kagamin wrote: On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin wrote: If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts. Manual memory management should be possible in D, see for example https://github.com/Dgame/m3 And since today it is @safe wherever possible.
Re: GC has a barbaric destroyng model, I think
On Wednesday, 11 February 2015 at 21:34:00 UTC, Andrey Derzhavin wrote: If we are using a DMD realization of destroying of objects, happens the following: at the calling the «destroy» method the calling of dtor takes place always, and then the object which is being destroyed is initialized by the default state. In other words, after calling «destroy» method, there is no way of getting an access to the members of the object that is being destroyed (it is meant, that the members are the references). GC works the same way. This approach in case of manual calling of «destroy» method has predictable and understandable consequences (there is no reasone to use the object being destroyed). But if GC performes the destroying of the objects, a lot of errors appear at the accessing to the members which are references, because some of them have already been destroyed (access to the members is realized in dtors). Such situations can be avoided, by using «@nogc» keyword. Howewer «@nogc» keyword doesn't protect us from using the references in dtors: we can assign some values to the refernces, we can have access to some members by the references and assign them some values.That is not correct in itself. If GC starts destroying some group of the objects, it could be more correct, if the calls of dtros are occured of all objects in a group before phisical memory releasing. Or GC must call dtors of the objetcts only, which noone refers to. The finalization order issue is one that is actually rather difficult, if not impossible, to solve without a precise GC. It gets even more complicated when you have to deal with cyclic references in finalizable allocations.
Re: GC has a barbaric destroyng model, I think
On Wed, 11 Feb 2015 21:33:59 +, Andrey Derzhavin wrote: If we are using a DMD realization of destroying of objects, happens the following: at the calling the «destroy» method the calling of dtor takes place always, and then the object which is being destroyed is initialized by the default state. In other words, after calling «destroy» method, there is no way of getting an access to the members of the object that is being destroyed (it is meant, that the members are the references). GC works the same way. This approach in case of manual calling of «destroy» method has predictable and understandable consequences (there is no reasone to use the object being destroyed). But if GC performes the destroying of the objects, a lot of errors appear at the accessing to the members which are references, because some of them have already been destroyed (access to the members is realized in dtors). Such situations can be avoided, by using «@nogc» keyword. Howewer «@nogc» keyword doesn't protect us from using the references in dtors: we can assign some values to the refernces, we can have access to some members by the references and assign them some values.That is not correct in itself. If GC starts destroying some group of the objects, it could be more correct, if the calls of dtros are occured of all objects in a group before phisical memory releasing. Or GC must call dtors of the objetcts only, which noone refers to. this problem has very easy solition: we should stop calling class dtors destructors, and rename them to finalizers. The field is lost Everything is lost The black one has fallen from the sky and the towers in ruins lie when finalizer is called, the battlefield is devastated, dead bodies lies everywhere, and so on. don't expect that those dead ones can still talk. signature.asc Description: PGP signature
GC has a barbaric destroyng model, I think
If we are using a DMD realization of destroying of objects, happens the following: at the calling the «destroy» method the calling of dtor takes place always, and then the object which is being destroyed is initialized by the default state. In other words, after calling «destroy» method, there is no way of getting an access to the members of the object that is being destroyed (it is meant, that the members are the references). GC works the same way. This approach in case of manual calling of «destroy» method has predictable and understandable consequences (there is no reasone to use the object being destroyed). But if GC performes the destroying of the objects, a lot of errors appear at the accessing to the members which are references, because some of them have already been destroyed (access to the members is realized in dtors). Such situations can be avoided, by using «@nogc» keyword. Howewer «@nogc» keyword doesn't protect us from using the references in dtors: we can assign some values to the refernces, we can have access to some members by the references and assign them some values.That is not correct in itself. If GC starts destroying some group of the objects, it could be more correct, if the calls of dtros are occured of all objects in a group before phisical memory releasing. Or GC must call dtors of the objetcts only, which noone refers to.
Re: GC has a barbaric destroyng model, I think
On Wednesday, February 11, 2015 21:40:30 Orvid King via Digitalmars-d-learn wrote: On Wednesday, 11 February 2015 at 21:34:00 UTC, Andrey Derzhavin wrote: If we are using a DMD realization of destroying of objects, happens the following: at the calling the «destroy» method the calling of dtor takes place always, and then the object which is being destroyed is initialized by the default state. In other words, after calling «destroy» method, there is no way of getting an access to the members of the object that is being destroyed (it is meant, that the members are the references). GC works the same way. This approach in case of manual calling of «destroy» method has predictable and understandable consequences (there is no reasone to use the object being destroyed). But if GC performes the destroying of the objects, a lot of errors appear at the accessing to the members which are references, because some of them have already been destroyed (access to the members is realized in dtors). Such situations can be avoided, by using «@nogc» keyword. Howewer «@nogc» keyword doesn't protect us from using the references in dtors: we can assign some values to the refernces, we can have access to some members by the references and assign them some values.That is not correct in itself. If GC starts destroying some group of the objects, it could be more correct, if the calls of dtros are occured of all objects in a group before phisical memory releasing. Or GC must call dtors of the objetcts only, which noone refers to. The finalization order issue is one that is actually rather difficult, if not impossible, to solve without a precise GC. It gets even more complicated when you have to deal with cyclic references in finalizable allocations. Yeah. And what it comes down to is that you don't access anything on the GC heap from a class' finalizer, which seriously limits what you can do with them. And yes, that can suck, but there isn't an easy solution - especially when you take cyclical references into account. Basically, don't use class finalizers unless you have to, and even then, only use them to access stuff that isn't on the GC heap. - Jonathan M Davis
