News for hackers. Stuff that matters.
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads by pjmlp on Wednesday August 05, 2020 @03:37PM (#24064681)
You can stack allocate objects, so those are alive just until the end of the stack.

Then there native memory allocation and safe handles.

IDisposable and Finalizers aren't the same thing, actually, although they happen to be used together as means to combine deterministic destruction alongside GC based destruction.

You can also make use of lambdas or implicit IDisposable implementations via helper methods, that generate code similar to memory regions or arenas in C++, but in .NET.

Finally, many tend to forget that .NET was designed to support C++ as well, so it is also possible to generate MSIL code that ensures deterministic destruction RAII style, naturally this falls into a bit more advanced programming, but it can be hidden away in helper classes.

Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads by algorithmsRcool on Wednesday August 05, 2020 @06:49PM (#24066455)
> You can stack allocate objects, so those are alive just until the end of the stack.

Well, not really. You cannot stack allocate anything but primitive buffers. So no objects or even strings. So it cannot replace heap allocation for anything but smallish "arrays" of simple types like char and int. This also means you can't use normal structs/value types, only primitives.

> You can also make use of lambdas or implicit IDisposable implementations via helper methods, that generate code similar to memory regions or arenas in C++, but in .NET.

> Finally, many tend to forget that .NET was designed to support C++ as well, so it is also possible to generate MSIL code that ensures deterministic destruction RAII style, naturally this falls into a bit more advanced programming, but it can be hidden away in helper classes.

I'm pretty sure there is no way in C# or in MSIL to explicitly free/deallocate a heap allocated object.

MSIL defines a Newobj opcode, but no Freeobj or anything like it that I have ever seen. You can use custom allocators or unmanaged memory to deterministically allocate and free buffers of structs/values types. But only those that do not include references to managed object references, otherwise you would need to pin and the references yourself and keep the GC aware that there were non-tracked references to those objects. It gets messy fast.

Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads by pjmlp on Thursday August 06, 2020 @02:04AM (#24068494)
It is so easy, write the code that you want in safe mode C++/CLI, get the code template, then implement the helper classes to generate the same MSIL on the fly.

As for stack allocation, apparently you missed structs.

Here is your string allocated on the stack.

    unsafe struct cppstring
    {
        const int BuffSize = 1024;
        fixed char data[BuffSize + 1];
        int current;
        
        public cppstring(System.ReadOnlySpan<char> buffer)
        {
            for (int i = 0; i < System.Math.Min(BuffSize, buffer.Length); i++)
                data[i] = buffer[i];
            current = 0;
        }
    }

    public class StackDemo {
        public void Myfunc() {
            var str = new cppstring ("Hello from stack");
        }
    }
Providing std::string like operations is left as exercise for the reader.
Re:Sub-10 ms Latency in Java: Concurrent GC with Green Threads by algorithmsRcool on Saturday August 08, 2020 @08:47PM (#24096418)
But that object is not a string, it is char buffer. You cannot directly substitute one for the other.

Yes I realize they can be used to store the same data, but you've defined a new type that is incompatible with an actual string object.