There are benchmarks.. :) The sad thing is that one can get only abstracts for these papers usually for free. While being at the university these were available, IEEE for instance.
And Java was slow because GUI programmers didn't undestand that one cannot do anything slow in the thread that delivers events to the application. But the same thing will happens in MS Windows unless one doesn't process the messages that MS is sending you. Probably everyone has seen Windows applications that go sometimes completely grey.
Also there are still people who think that Java "is slow, because it is interpreted".
It just needs to be accessible from a root (eg. a global variable or a data structure that has a longer lifespan than the object it references). Most programs use global variables or classes that contain pointers to major data structures so that they are easily accessible. Another common thing is to build auxiliary data structures to augment an existing data structure. This often involves pointers going both ways, so they become intertwined. At some point you've done the work and want to delete the auxiliary data structure. Now how do you do this in a GC world?
The key problem here is that a data structure may be referred to from many places, so if you want to remove it you really have to remove all references to it.
There is a difference. In the malloc/free case you only need to call free once on an object and it will be reused, even if some other data structures still point to it (if they actually access it, it is a bug of course). In the GC case you either have to clean up all dangling references, or hope all they will go out of scope soon.
You're right that with correct design and correct variable scoping (especially of the roots that point to big data structures) and avoiding copying pointers all over the place (or intertwining data structures as described above), you can get GC to work perfectly. But all this requires extra programming effort.
You can do the same with explicit memory management. I often use what you could describe as explicit garbage collection, which is allocate all data for a datastructure in a single memory block, and release it in one go when done with it, thus avoiding a complex traversal.
By "going both ways", do you mean cyclic references?
In the context on this group, why the process/thread/bla should ever quit? Even if it does it is up to the OS to release all the resources, what the process forgot to release.
In the Singleton pattern, many instances use the Singleton.getInstace() call for doing work. Then they simply forget it. It is just bad design to hold a reference to a Singleton, that is what for this pattern is about.
(although this not that much of GC, but I just tried to think of a usage pattern how you are justifying your claims)
course).
I have been involved with several server side stuff. It is only very few references that "stay alive" in the whole life of the process.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.