Some thoughts on the .net CLR/CLI
-
I just use dispose. if you don't dispose your disposable unmanaged resources, you suck at coding. I won't make the rest of the end developers pay in GC performance for that lack of skill =D /the true bastard coder from hell
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
well there are case were using Dispose is not quite practical... Further if you write a class using unmanaged resource, you can't rely on your user calling Dispose. You can hope they do call Dispose, but it's even better if you can make it work regardless! ;) i.e. it's better if your class doesn't memory leak regardless whether whoever use it call Dispose or not. The whole point of .NET is that .NET class don't give headache to whoever uses them! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
what what? ooooh. I'll definitely check it out. it sounds interesting.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Let us know what you find. From what I've read I think they're just limiting what language features they use to control memory allocations, but I've just read a few blogs and never tried anything.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Let us know what you find. From what I've read I think they're just limiting what language features they use to control memory allocations, but I've just read a few blogs and never tried anything.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
They appear to have some new syntax, among them "#include". Not sure if it's limited to a preprocessor or not, but they're talking about rendering to machine code, not IL
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
well there are case were using Dispose is not quite practical... Further if you write a class using unmanaged resource, you can't rely on your user calling Dispose. You can hope they do call Dispose, but it's even better if you can make it work regardless! ;) i.e. it's better if your class doesn't memory leak regardless whether whoever use it call Dispose or not. The whole point of .NET is that .NET class don't give headache to whoever uses them! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I mean, probably, but I don't usually code for VB developers :suss:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I mean, probably, but I don't usually code for VB developers :suss:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
you sound like you didn't give how to use unmanaged resource any sort of serious thought! :rolleyes: to be fair.. in the last 10 years I never had to use unmanaged resource (explicitly) in .NET! But you have to keep in mind. 1. .NET use a lot of unmanaged resource. But it's done in a lot of nicely encapsulated OS/Utility class. For example WPF use tons of them to render DirectX content. It's also very common in WinForm, all those Bitmap, Cursor, Brush, etc... all wrap unmanaged OS resources. 2. once upon a time, before .NET 3.5, one often had to use unmanaged resource explicitly to use OS class not nicely wrapped. Hence how to properly use them was much more common knowledge back then. Additionally what has unmanaged resources to do with VB? If anything, my natural prejudice against VB developers would have me say that VB developer can't properly handle unmanaged resources! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
you sound like you didn't give how to use unmanaged resource any sort of serious thought! :rolleyes: to be fair.. in the last 10 years I never had to use unmanaged resource (explicitly) in .NET! But you have to keep in mind. 1. .NET use a lot of unmanaged resource. But it's done in a lot of nicely encapsulated OS/Utility class. For example WPF use tons of them to render DirectX content. It's also very common in WinForm, all those Bitmap, Cursor, Brush, etc... all wrap unmanaged OS resources. 2. once upon a time, before .NET 3.5, one often had to use unmanaged resource explicitly to use OS class not nicely wrapped. Hence how to properly use them was much more common knowledge back then. Additionally what has unmanaged resources to do with VB? If anything, my natural prejudice against VB developers would have me say that VB developer can't properly handle unmanaged resources! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Actually have given it a lot of thought, and in the end I decided not to use Finalizers. Here's why, and I think it's justifiable: Win32 process segregation. You will clean all handles on proc exit RIGHT AFTER the GC cleans up it's Finalized objects. Win32 handles what .NET won't, usually at the same time. There's one exception - remote COM objects. I will clear handles on those, but doing RPC is its own topic, and lifetime considerations are a huge one. As far as your final sentence, that was rather my point. My audience isn't VB developers. If I was targeting them I'd make my code drool proof. =)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Actually have given it a lot of thought, and in the end I decided not to use Finalizers. Here's why, and I think it's justifiable: Win32 process segregation. You will clean all handles on proc exit RIGHT AFTER the GC cleans up it's Finalized objects. Win32 handles what .NET won't, usually at the same time. There's one exception - remote COM objects. I will clear handles on those, but doing RPC is its own topic, and lifetime considerations are a huge one. As far as your final sentence, that was rather my point. My audience isn't VB developers. If I was targeting them I'd make my code drool proof. =)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
At any rate I don't understand your beef against finalizers.. 1. it avoids memory / resource leaks regardless of whoever use your API. i.e. it makes garbage collection collect your resources, isn't that nice? 2. it has no performance impact if you call Dispose explicitly 3. it's 3 line of code to implement properly... therefore I am just completely nonplussed by your... reluctance about them... :omg: :wtf: :confused::~
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
At any rate I don't understand your beef against finalizers.. 1. it avoids memory / resource leaks regardless of whoever use your API. i.e. it makes garbage collection collect your resources, isn't that nice? 2. it has no performance impact if you call Dispose explicitly 3. it's 3 line of code to implement properly... therefore I am just completely nonplussed by your... reluctance about them... :omg: :wtf: :confused::~
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I just don't have a good enough justification to use because it doesn't prevent resource leaks - win32 does that, as I said. I've never seen .NET even call finalizers 99% of the time until just before process exit. Which means your VB developer who is not using anything like using(var brush = ) is still creating a ton of handles that will remain uncollected for the lifetime of the app. And GC has no way of knowing when GDI is out of handles. So it just lets them get eaten, even with your finalizers. Until your proc exits. At which point win32 cleans up anyway. Now tell me I'm wrong about any of this?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I just don't have a good enough justification to use because it doesn't prevent resource leaks - win32 does that, as I said. I've never seen .NET even call finalizers 99% of the time until just before process exit. Which means your VB developer who is not using anything like using(var brush = ) is still creating a ton of handles that will remain uncollected for the lifetime of the app. And GC has no way of knowing when GDI is out of handles. So it just lets them get eaten, even with your finalizers. Until your proc exits. At which point win32 cleans up anyway. Now tell me I'm wrong about any of this?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
codewitch honey crisis wrote:
I just don't have a good enough justification to use because it doesn't prevent resource leaks - win32 does that, as I said.
This class is potentially leaking, and Win32 is NOT magically fixing it.
public class Class : IDisposable { IntPtr unmanaged; public Class() { unmanaged = Marshal.AllocHGlobal(10); } public void Dispose() { Marshal.FreeHGlobal(unmanaged); unmanaged = IntPtr.Zero; } }And this class is not leaking and is nicely garbage collected.
public class Class : IDisposable { IntPtr unmanaged; public Class() { unmanaged = Marshal.AllocHGlobal(10); } ~Class() { Dispose(false); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected void Dispose(bool disposing) { Marshal.FreeHGlobal(unmanaged); unmanaged = IntPtr.Zero; }but the real question is... why do you refuse to do implementation 2? What so complicated or costly about it? Why do you so adamantly want to introduce memory leak? That doesn't make no sense! :omg: :confused: BTW bonus implementation with explicit memory pressure
public class Class : IDisposable { IntPtr unmanaged; public Class() { unmanaged = Marshal.AllocHGlobal(10); GC.AddMemoryPressure(10); } ~Class() { Dispose(false); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected void Dispose(bool disposing) { if (unmanaged != IntPtr.Zero) { Marshal.FreeHGlobal(unmanaged); GC.RemoveMemoryPressure(10); unmanaged = IntPtr.Zero; } } }A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
codewitch honey crisis wrote:
I just don't have a good enough justification to use because it doesn't prevent resource leaks - win32 does that, as I said.
This class is potentially leaking, and Win32 is NOT magically fixing it.
public class Class : IDisposable { IntPtr unmanaged; public Class() { unmanaged = Marshal.AllocHGlobal(10); } public void Dispose() { Marshal.FreeHGlobal(unmanaged); unmanaged = IntPtr.Zero; } }And this class is not leaking and is nicely garbage collected.
public class Class : IDisposable { IntPtr unmanaged; public Class() { unmanaged = Marshal.AllocHGlobal(10); } ~Class() { Dispose(false); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected void Dispose(bool disposing) { Marshal.FreeHGlobal(unmanaged); unmanaged = IntPtr.Zero; }but the real question is... why do you refuse to do implementation 2? What so complicated or costly about it? Why do you so adamantly want to introduce memory leak? That doesn't make no sense! :omg: :confused: BTW bonus implementation with explicit memory pressure
public class Class : IDisposable { IntPtr unmanaged; public Class() { unmanaged = Marshal.AllocHGlobal(10); GC.AddMemoryPressure(10); } ~Class() { Dispose(false); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected void Dispose(bool disposing) { if (unmanaged != IntPtr.Zero) { Marshal.FreeHGlobal(unmanaged); GC.RemoveMemoryPressure(10); unmanaged = IntPtr.Zero; } } }A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Again, Win32 cleans up that HGLOBAL leak on process exit. So does Finalize. Maybe if I'm slamming the garbage collector i can get finalize to be called before proc exit. in the real world i've pretty much never seen that happen. so until they do, I see no reason to use it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
codewitch honey crisis wrote:
I just don't have a good enough justification to use because it doesn't prevent resource leaks - win32 does that, as I said.
This class is potentially leaking, and Win32 is NOT magically fixing it.
public class Class : IDisposable { IntPtr unmanaged; public Class() { unmanaged = Marshal.AllocHGlobal(10); } public void Dispose() { Marshal.FreeHGlobal(unmanaged); unmanaged = IntPtr.Zero; } }And this class is not leaking and is nicely garbage collected.
public class Class : IDisposable { IntPtr unmanaged; public Class() { unmanaged = Marshal.AllocHGlobal(10); } ~Class() { Dispose(false); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected void Dispose(bool disposing) { Marshal.FreeHGlobal(unmanaged); unmanaged = IntPtr.Zero; }but the real question is... why do you refuse to do implementation 2? What so complicated or costly about it? Why do you so adamantly want to introduce memory leak? That doesn't make no sense! :omg: :confused: BTW bonus implementation with explicit memory pressure
public class Class : IDisposable { IntPtr unmanaged; public Class() { unmanaged = Marshal.AllocHGlobal(10); GC.AddMemoryPressure(10); } ~Class() { Dispose(false); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected void Dispose(bool disposing) { if (unmanaged != IntPtr.Zero) { Marshal.FreeHGlobal(unmanaged); GC.RemoveMemoryPressure(10); unmanaged = IntPtr.Zero; } } }A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Let be me more explicit here. A) You cannot leak HGLOBAL outside of a process. Any process allocated resource will be freed on process exit, managed or not. B) Finalized objects are placed in a special list, and generally their finalizers get called right before proc exit. Since A, B is redundant. Meaning the code is redundant. I don't leak. And I don't use finalize. But I do dispose. The exception is maybe RPC, but worst I'd maybe do this #if DEBUG void Finalize() {if(!_isDisposed) {System.Diagnostics.Debug.WriteLine("Error: Object not disposed"); System.Diagnostics.Debugger.Break();} } #endif DEBUG so you could catch it in a debug session. I don't believe in using that set aside list - it adds unnecessary churn to the GC. I'd rather report the failure, because if you're not disposing you're also running into other problems finalize won't help you with - like stepping on unclosed files or worse, running out of GDI handles. Before finalize ever gets a chance to be called. At any rate, I don't use unmanaged resources directly on serious projects, so you won't find it an issue in my code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Let be me more explicit here. A) You cannot leak HGLOBAL outside of a process. Any process allocated resource will be freed on process exit, managed or not. B) Finalized objects are placed in a special list, and generally their finalizers get called right before proc exit. Since A, B is redundant. Meaning the code is redundant. I don't leak. And I don't use finalize. But I do dispose. The exception is maybe RPC, but worst I'd maybe do this #if DEBUG void Finalize() {if(!_isDisposed) {System.Diagnostics.Debug.WriteLine("Error: Object not disposed"); System.Diagnostics.Debugger.Break();} } #endif DEBUG so you could catch it in a debug session. I don't believe in using that set aside list - it adds unnecessary churn to the GC. I'd rather report the failure, because if you're not disposing you're also running into other problems finalize won't help you with - like stepping on unclosed files or worse, running out of GDI handles. Before finalize ever gets a chance to be called. At any rate, I don't use unmanaged resources directly on serious projects, so you won't find it an issue in my code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
yes, on process exit memory is collected. but general purpose class in a reusable library should not limit to such narrow scenario (of short living utility process). Particularly when there is an easy 3 line fix. For example what if you wrapped an HBITMAP in a nice C# resource in a drawing program that can be left open for hours or days.. but every now and then the computer will slow down dramatically and the user will reboot because he has no idea what's going on... or maybe he will investigate the problem and realize it's that "shit drawing program" that is leaking memory again! That's not something I want to happens to my users... Or for another example you got this webserver running 24/7 serving millions request every hours.... But then, suddenly, the process becomes super slow and the webserver need be restarted every hour it turns out. unacceptable! Finally do you really want to tell a potential job interviewer you don't bother making your resource garbage collection friendly because one can just restart the application?! :omg:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
yes, on process exit memory is collected. but general purpose class in a reusable library should not limit to such narrow scenario (of short living utility process). Particularly when there is an easy 3 line fix. For example what if you wrapped an HBITMAP in a nice C# resource in a drawing program that can be left open for hours or days.. but every now and then the computer will slow down dramatically and the user will reboot because he has no idea what's going on... or maybe he will investigate the problem and realize it's that "shit drawing program" that is leaking memory again! That's not something I want to happens to my users... Or for another example you got this webserver running 24/7 serving millions request every hours.... But then, suddenly, the process becomes super slow and the webserver need be restarted every hour it turns out. unacceptable! Finally do you really want to tell a potential job interviewer you don't bother making your resource garbage collection friendly because one can just restart the application?! :omg:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Show me where Finalized objects get collected before proc exit in a real world scenario. Except server apps, but if you're using unmanaged resources directly from a webserver i hate you. In application code, the GC calls finalizer before proc exit. Show me where it doesn't. Contrive a scenario even. It won't slow down dramatically until reboot. The kernel keeps an slist of kernel handles by process around. Win32 does indeed clean them when the process exits. Your HBITMAP will be around until proc exit, not until reboot. And *it would anyway* - at least in my tests, because Finalize doesn't get called until proc exit anyway.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
yes, on process exit memory is collected. but general purpose class in a reusable library should not limit to such narrow scenario (of short living utility process). Particularly when there is an easy 3 line fix. For example what if you wrapped an HBITMAP in a nice C# resource in a drawing program that can be left open for hours or days.. but every now and then the computer will slow down dramatically and the user will reboot because he has no idea what's going on... or maybe he will investigate the problem and realize it's that "shit drawing program" that is leaking memory again! That's not something I want to happens to my users... Or for another example you got this webserver running 24/7 serving millions request every hours.... But then, suddenly, the process becomes super slow and the webserver need be restarted every hour it turns out. unacceptable! Finally do you really want to tell a potential job interviewer you don't bother making your resource garbage collection friendly because one can just restart the application?! :omg:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Adding, I hope you never count on those finalizers being called. Designing your code such that they are dependant on them in any way is terrible design. If I want to truly manage the disposal of objects, I'll keep a list of them and track them myself. That's the proper way to do it. Always Call Dispose. On any disposable interface. If you don't do it assume you are leaking If you want to use that additional set aside GC list for finalization be my guest, but your users are WRONG if they ever write code that needs it. And I'd rather ASSERT that sort of wrong then try to manage it, because of the other problems i mentioned. Consider this: - and I've done this on a web server in the real world and learned the hard way - which is one of the reasons i don't use finalize anymore! Create GDI ico handles by using shell calls. Forget to call dispose on a few of them, but implement finalizers. I'll bet you my next check you run out of GDI handles and your system just stops producing more. Until you restart the webserver This is WITH your finalizers. At least if you ASSERT you'll eventually get a debug on what happened. I learned the hard way.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Show me where Finalized objects get collected before proc exit in a real world scenario. Except server apps, but if you're using unmanaged resources directly from a webserver i hate you. In application code, the GC calls finalizer before proc exit. Show me where it doesn't. Contrive a scenario even. It won't slow down dramatically until reboot. The kernel keeps an slist of kernel handles by process around. Win32 does indeed clean them when the process exits. Your HBITMAP will be around until proc exit, not until reboot. And *it would anyway* - at least in my tests, because Finalize doesn't get called until proc exit anyway.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
this is going nowhere so I will stop trying to convince to write proper utility classes. although I will just add 2 (last) things: - for the record memory management, and even dispose, is indeed totally useless if all you have is short running processes. the issue is all about singular long running process running as long as possible. which you seem to dismiss so casually for some mysterious reason - you were asking for a sample that show if finalizer are even ever called. well run the winform app below as a console app (to see the Console.WriteLine() output), press the button a few times, tab out and in, do it again. you will see that finalizer are indeed called sometimes.
class Program { static void Main(string\[\] args) { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MyForm()); } } public class MyForm : Form { public MyForm() { var b = new Button { Text = "Click", Dock = System.Windows.Forms.DockStyle.Fill, }; b.Click += (o, e) => { new Foo(); }; this.Controls.Add(b); } } public class Foo { const int N = 100\_000; IntPtr unmanaged; public Foo() { unmanaged = Marshal.AllocHGlobal(N); GC.AddMemoryPressure(N); } ~Foo() { Console.WriteLine("in finalizer"); // not freeing any memory on purpose //Marshal.FreeHGlobal(unmanaged); //GC.RemoveMemoryPressure(N); } }A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
this is going nowhere so I will stop trying to convince to write proper utility classes. although I will just add 2 (last) things: - for the record memory management, and even dispose, is indeed totally useless if all you have is short running processes. the issue is all about singular long running process running as long as possible. which you seem to dismiss so casually for some mysterious reason - you were asking for a sample that show if finalizer are even ever called. well run the winform app below as a console app (to see the Console.WriteLine() output), press the button a few times, tab out and in, do it again. you will see that finalizer are indeed called sometimes.
class Program { static void Main(string\[\] args) { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MyForm()); } } public class MyForm : Form { public MyForm() { var b = new Button { Text = "Click", Dock = System.Windows.Forms.DockStyle.Fill, }; b.Click += (o, e) => { new Foo(); }; this.Controls.Add(b); } } public class Foo { const int N = 100\_000; IntPtr unmanaged; public Foo() { unmanaged = Marshal.AllocHGlobal(N); GC.AddMemoryPressure(N); } ~Foo() { Console.WriteLine("in finalizer"); // not freeing any memory on purpose //Marshal.FreeHGlobal(unmanaged); //GC.RemoveMemoryPressure(N); } }A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I'll try running that. But yeah for now, let's agree to disagree. I'll kick around what you wrote. You may have changed my mind if that sample pans out. The last time i actually tested this was pre .NET 3
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
this is going nowhere so I will stop trying to convince to write proper utility classes. although I will just add 2 (last) things: - for the record memory management, and even dispose, is indeed totally useless if all you have is short running processes. the issue is all about singular long running process running as long as possible. which you seem to dismiss so casually for some mysterious reason - you were asking for a sample that show if finalizer are even ever called. well run the winform app below as a console app (to see the Console.WriteLine() output), press the button a few times, tab out and in, do it again. you will see that finalizer are indeed called sometimes.
class Program { static void Main(string\[\] args) { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MyForm()); } } public class MyForm : Form { public MyForm() { var b = new Button { Text = "Click", Dock = System.Windows.Forms.DockStyle.Fill, }; b.Click += (o, e) => { new Foo(); }; this.Controls.Add(b); } } public class Foo { const int N = 100\_000; IntPtr unmanaged; public Foo() { unmanaged = Marshal.AllocHGlobal(N); GC.AddMemoryPressure(N); } ~Foo() { Console.WriteLine("in finalizer"); // not freeing any memory on purpose //Marshal.FreeHGlobal(unmanaged); //GC.RemoveMemoryPressure(N); } }A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I should add, the only time I'll write a "Utility" class it's static. I use the convention a lot, but never for anything instantiated. That's just me. =) so when you said Utility class my first thought, was , where would I keep the state? :confused: At any rate, it impacts nothing I've written since .NET 2 days, but if I do write some unmanaged wrapper I'll keep this exchange in mind.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Show me where Finalized objects get collected before proc exit in a real world scenario. Except server apps, but if you're using unmanaged resources directly from a webserver i hate you. In application code, the GC calls finalizer before proc exit. Show me where it doesn't. Contrive a scenario even. It won't slow down dramatically until reboot. The kernel keeps an slist of kernel handles by process around. Win32 does indeed clean them when the process exits. Your HBITMAP will be around until proc exit, not until reboot. And *it would anyway* - at least in my tests, because Finalize doesn't get called until proc exit anyway.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I don't think it matters when I analyse your opinion but... I want to point out that while finalizers are unpredictable, that doesn't mean they are unreliable. Finalizers are very reliable. But they only happens once in a while.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I don't think it matters when I analyse your opinion but... I want to point out that while finalizers are unpredictable, that doesn't mean they are unreliable. Finalizers are very reliable. But they only happens once in a while.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
What I mean is you can't rely on them to close something before you run into trouble. Again, this may have changed in newer .NET renditions - since i tested which was a decade ago at least. It looks like your sample does indeed finalize on collect. Still, I question whether it would collect often enough to keep up with the leakage from not calling dispose. It never did in the past for me.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
What I mean is you can't rely on them to close something before you run into trouble. Again, this may have changed in newer .NET renditions - since i tested which was a decade ago at least. It looks like your sample does indeed finalize on collect. Still, I question whether it would collect often enough to keep up with the leakage from not calling dispose. It never did in the past for me.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I have trouble understanding your statements... So here are some facts... Using memory pressure hint you can be sure it will suggest to the runtime enough GC that you don't run out of memory or become slow or fragmented. This is, however, something that is only marginally useful, I didn't notice any obvious improvement after using that hit. I guess I never allocated huge unmanaged memory pages. If your code is using other precious system resource, like a Window handle, or a brush handle or a socket... you might be out of luck. You might run out those without the system realizing a system GC is needed. I can't even start to guess what you mean when you wrote "finalizer keep up with the leakage from not calling dispose"
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!