Some thoughts on the .net CLR/CLI

[honey the codewitch]

I wasn't going to tell him. Anyone that uses Finalizers needs to be dragged into the street and summarily shot. With witnesses so nobody *ever* makes the same mistake. There's a special hell where they keep the guy who designed them. It's below building 8 on the microsoft campus.

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.

[honey the codewitch]

seems accurate. it even kinda looks like HAL

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.

[Dan Neely]

You might want to look at what Unity is doing with what they're calling High Performance C#. AIUI a big part is limiting themselves to stack allocations and language features that don't do heap allocations in the background to get C++ish equivalent performance/consistency by avoiding ever triggering GCs. You probably don't need the verifiably vectorized capabilities they've also built into their toolchain; but borrowing an off the shelf solution might be easier than doing the parts you need on your own. [C++, C# and Unity](https://lucasmeijer.com/posts/cpp\_unity/)

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

[Sander Rossel]

I'm told tuples use them too :laugh:

Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly

[honey the codewitch]

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.

[Gary R Wheeler]

Being thoroughly experienced in C++, C#, and near-real-time programming, I've always been bemused by the complaints of performance issues related to garbage collection in .NET. I've never had a performance concern in my C# code that I could attribute to the GC taking over the machine. It's always been thread contention between resources, poorly thought-out locks, misuse of .NET facilities, or something similar. My opinion is that if your performance constraints are that tight, you shouldn't be using a garbage-collected language anyway. You need C or C++ and native threading constructs so that your control is as close to the bare metal as possible.

Software Zen: delete this;

[honey the codewitch]

Oh if you've ever tried to realtime audio apps you'll find out real quick. You can't even play midi on your own using midiout/send at anything 96ppm or above without GC forcing you to drop frames or lag periodically. suspend the GC like 4+ allows you to, the problem disappears, but you have to reserve reams of heap to do it. I think your lack of running into the problem may be more due to the lack of trying to do anything crazy like that with C#? I wouldn't have even tried, *precisely because* of my experience with C++ and RTOS apps except i was looking into the GC issue and looking at how realistic .NET 4+ suspend GC/critical region feature was to use in practice, so i developed some realtime code to test it. something sensitive. Ears are more time sensitive than eyes, so I wrote a midi player. I've tested the results. I *could* post the project here just to settle the point, but it seems a lot of work just to do 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.

[Super Lloyd]

Finalizers are kind of mandatory if C# object create native resource through interop. An increasingly rare occurrence those days to be sure, but it still happens. Also MS Style cop thingy complains if you don't have a finalizer on IDisposable class. I disable that silly warning... But some people chose to follow it.

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[honey the codewitch]

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.

[Super Lloyd]

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!

[Dan Neely]

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

[honey the codewitch]

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.

[honey the codewitch]

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.

[Super Lloyd]

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!

[honey the codewitch]

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.

[Super Lloyd]

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!

[honey the codewitch]

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.

[Super Lloyd]

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!

[honey the codewitch]

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.

[honey the codewitch]

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.