-2

Hello I was googling about why is there not a manual specific object deletion function. (The process that java garbage collection is doing manually.)
It always confused me. I know that you can't do it and that you should not call the System#gc() but I couldn't find any results on why you can't do it.
Why let gc check if object is in isolation island and waste cpu instead of deleting it yourself when you are 100% sure that the object won't be used again.
Note: I am not talking about calling gc to discard all unused objects. I am talking about deleting a single object (and it's children).

LapisSea
  • 83
  • 1
  • 9
  • 5
    Because memory management is not as easy as you think it is – Sleiman Jneidi Apr 29 '16 at 21:34
  • 2
    Assumptions that aren't actually necessarily true from your post: GC takes time to delete objects (it's live objects that cost, not dead objects); deleting an object actually buys you anything (depending on how your heap works it doesn't necessarily); programmers are actually trustworthy about when objects are dead (they aren't). – Louis Wasserman Apr 29 '16 at 21:35
  • Thanks for helpful and descriptive reply. :) – LapisSea Apr 29 '16 at 21:35
  • 2
    Note that even in C++, where manual object deletion does exist, experts like [Herb Sutter](https://herbsutter.com/2013/05/29/gotw-89-solution-smart-pointers/) suggest that you should never actually manually delete an object using delete, instead preferring to use smart pointers to do the memory management for you. – Andy Turner Apr 29 '16 at 21:39
  • The rule is that an object is eligible to GC if it's not strongly reachable anymore. If you can delete it explicitly, it means that you have a strong reference to it, and that it's thus reachable, and should thus not be garbage-collected. You also can't ensure that its not reachable through another path. So even if it was possible to do it, the system would have to check that it's not reachable except through the reference path you're using to access the object. That would most probably either be less efficient than the GC, or the source of countless very hard to diagnose bugs. – JB Nizet Apr 29 '16 at 21:42
  • @JBNizet Java does have weak pointers (called WeakReference). You can hold a weak reference to an object and still be able to reach it (but not strongly). Java even has a whole WeakHashMap for holding weak references. – Polygnome Apr 29 '16 at 21:46
  • @Polygnome But at the point when you call `weakReference.get()`, you make the object strongly reachable again (if it wasn't already). No matter what you, you can't pass a non-reachable object to anywhere. What JBNizet says is that you could manually only free objects not eligible for GC. – maaartinus May 01 '16 at 01:26

1 Answers1

1

If you're absolutely sure the object can be deleted there is a way: just null the last reference to that object, and the GC will care about the rest.

The reason manual memory management is unsafe is that while you might be right that the object is ripe for deletion, this is only true for the current state of a program. It could become false after some refactoring or further development of the code, and there is no way to reason about it. In a programming language with objects that hold references to each other that are mutated all the time, it doesn't need too much until the potential object graph is so huge that no human can actually say what is referencing what.

Ingo
  • 36,037
  • 5
  • 53
  • 100
  • Although I agree with the content of your answer, it doesn't really answer the OPs question in my opinion. – Austin Apr 29 '16 at 21:48
  • @Austin I've tried to explain that the idea of being "100% sure the object can be deleted" is in general self deceit. – Ingo Apr 29 '16 at 21:50
  • I would say that *we* can rarely be absolutely sure that the object can be deleted, as there is no strict ownership in Java: all we can say is that we no longer care if the object exists, by replacing the reference with some other value. Nulling out our reference doesn't necessarily cause it to be deleted, it merely removes "our objection" to it being deleted. – Andy Turner Apr 29 '16 at 21:51
  • Yeah thanks. I know that but I just thought that there should be a function for instant discarding of an object for large databases. For an example I have a for loop that runs 100 times. Every time it runs it creates 2GB of objects that are not used any more when next for loop iteration starts. Since gc does not run instantly (or before the next iteration) you are looking at a lot more memory used at times than it would be if you call deletion of specific objects at the end of the iteration. Call me crazy but does that seem like no problem? – LapisSea Apr 29 '16 at 21:54
  • @LapisSea Usually not. But you can still write code that performs badly, e.g. by creating enormous GC pressure. In some cases using pools of re-usable objects helps, or often changing some strategy, e.g. continously "streaming" data from the database instead of processing big chunks at once. – zapl Apr 29 '16 at 22:11
  • @LapisSea You can't reclaim garbage in Java by default. However, can't you use other languages? If you must use Java, take a look at https://github.com/OpenHFT/Chronicle-Queue – Kedar Mhaswade Apr 29 '16 at 22:16
  • 1
    @LapisSea the GC gets run whenever the heap is full. Java won't expand the size of the heap without running a GC first, so you can't actually end up using "a lot more memory" than you would anyway. – Louis Wasserman Apr 29 '16 at 22:19
  • Ok thanks! @LouisWasserman – LapisSea Apr 30 '16 at 05:46
  • @LapisSea Freeing manually would only make sense when 1. you could be sure, you hold the only reference, 2. dealing with garbage was faster than dealing with live objects, 3. freeing objects manually could help the GC. *None of the assumptions holds.* Concerning 2: In the new generation, there's much more garbage than live objects and GC actually works by moving the survivors away, so it does less work than you'd do. Concerning 3: Dealing with live and dead objects can't be efficiently combined. – maaartinus May 01 '16 at 01:33