31–40 of 77 posts
Anyone have a good comparison of .net vs java GCs? I never had trouble with the former but Java has been terrible. I'm not sure if its just my project or having the xmx memory cap.
How do I know this person really knows about .NET GC internals for me to spend any time watching some videos?
https://raw.githubusercontent.com/dotnet/runtime/master/src/...
Or spend an hour listening to this person. Who knows his videos might have some bits of important information.
Please forgive me ignorance, but why can't I manually delete an object? Lots of times I know this one object is pretty big and want to delete it when I am done with it, but have to force the GC to run to clean it up.
Because they're memory objects that are managed by .Net. If you said "Hey, I'm done with this" that's great, but .Net can't actually delete it until it's checked for itself that nothing else is using it. Otherwise you'll inject an error into the memory manager when you delete an object that's still in use. So you can kinda fake a delete by releasing the last reference to an object and then forcing a garbage collectio…
I had instances where I knew only one of these large structures could fit in memory and had to call gc.collect before allocating a new one, as I would get an outofmemory exception before the garbage collector would kick in by itself.
You can do that with unmanaged objects but it doesn't look like you can with managed objects (other than gc.collect which I saw on other videos is not recommended by microsoft).
Please forgive me ignorance, but why can't I manually delete an object? Lots of times I know this one object is pretty big and want to delete it when I am done with it, but have to force the GC to run to clean it up.
With a GC like the one used in .NET, «deleting» an object is a noop. It wouldn’t give you any benefits over not deleting it. You only pay a price for living things (as in, some object holding a reference to it), the rest is free.
Please forgive me ignorance, but why can't I manually delete an object? Lots of times I know this one object is pretty big and want to delete it when I am done with it, but have to force the GC to run to clean it up.
Then you can allocate and deallocate at will.
Or just use a struct.
Earlier quoted context omitted.
With a GC like the one used in .NET, «deleting» an object is a noop. It wouldn’t give you any benefits over not deleting it. You only pay a price for living things (as in, some object holding a reference to it), the rest is free.
No I had instances where I deleted an object, wanted to allocate a new one, only one of these would fit in memory, and got an outofmemory exception because the GC didn't kick in between the two. So it is not equivalent.
I believe objects with destructors can keep an object alive for an extra collection phase, but I believe if that’s the case it can easily be solved with a using block before allocating the next object.
Maybe for some readers: Likely GC abbreviates garbage collection . Going way back, some programming languages have permitted dynamic storage allocation , that is, a programmer using that language could during execution of the program ask for storage , that is, bytes in main memory, to be allocated , i.e., made available for use. Later the programming could free that storage. E.g., early versions of the programming la…
> E.g., early versions of the programming language Fortran did not offer dynamic storage allocation, but some programmers would implement their own, say, in a Fortran array. Then for pointers to the allocated storage, just use a subscript on the array name. Even today people do the same thing in languages like Java and Rust as workarounds for performance or semantic constraints of the environment while still nominall…
Pointers require hardware support for the same purpose, which Oracle, ARM, Microsoft, Apple and Google are putting money into to, as means to fix C and C++.
Earlier quoted context omitted.
No I had instances where I deleted an object, wanted to allocate a new one, only one of these would fit in memory, and got an outofmemory exception because the GC didn't kick in between the two. So it is not equivalent.
The GC kicks in when allocating a new object and it decides it needs more memory. GC likely kicked in as you allocated the last object, and after the collection phase, still didn’t have enough memory and so failed. I believe objects with destructors can keep an object alive for an extra collection phase, but I believe if that’s the case it can easily be solved with a using block before allocating the next object.
Earlier quoted context omitted.
Because they're memory objects that are managed by .Net. If you said "Hey, I'm done with this" that's great, but .Net can't actually delete it until it's checked for itself that nothing else is using it. Otherwise you'll inject an error into the memory manager when you delete an object that's still in use. So you can kinda fake a delete by releasing the last reference to an object and then forcing a garbage collectio…
But gc.collect is quite expensive. I think the parent question was, I have a large object in memory, I want to delete it now so that I can load another large object without running into memory limits. But I don't want to call gc.collect which will stop my whole application, interfer with the garbage collector heuristics, and do all sort of unecessay steps. I had instances where I knew only one of these large structur…