Sure you can look at machine code generated from a virtualized language but I'd have a tough time understanding it in the context of the whole runtime, let alone being able to practically do anything about it.
It is no different than using -S and check what happens for several code patterns.
I doubt very seriously that anyone can write code in large teams where Valgrind will state there aren't double frees, bad frees, or dangling pointers happening.
Or a run with Coverity will state everything is nice and shinning.
Once upon a time I had to write a tool in a well known particle accelerator research institute to track down C++ memory errors in a multi-thread environment for cluster algorithms used in data analysis. As one common problem on that specific team was plugins bringing the cluster down due to memory corruption.
So I also do know one or two things about manual memory management.
And with what I know, I rather use automatic memory management, be it in the form of GC, RC, affine types or dependent types.
Its funny since I actually started writing code for particle accelerator research as well, although it was a mixture of terrible C and F77. Physicists and mathematicians are good at their respective fields, but not necessarily coding sadly (I used to be both). Would the code have been better with a different language? Doubtful. They used literally zero established patterns and wrote everything with copy paste and with zero regard for what the machine actually did.
To each their own though. I'm glad your projects and line of work afford you the ability to work with a GC. Mine do not.
Which comes back to my point that only developers able to get hired at that level are able to do manual memory management in large scale.
And even then, they resort to automatic memory management at higher levels in their stacks.
> I can look at the dissassembly and see exactly what's going on. I can't do this with Java, Python, Ruby, etc.
Just get a commercial JVM compiler, JIT Watch, Intel Amplifier. All of them provide the option to show the generated machine code.
> There's a reason DirectX12 is looked forward to. I don't want Windows reference counting my things any more unless I tell it to.
Better stop developing for Windows then.
The Universal Windows Application model is the continuation of WinRT, an evolution of COM.
In case you missed the note, DirectX 12 is still based on COM.
Also the new User Driver Model is based on COM.