
Ask HN: Why do langs with alleged “automatic memory management manage tiny part - ErotemeObelus
Java boasts it has automatic memory management. But you have to close files after using them. That&#x27;s manual memory management!
======
tjansen
Closing files manually is manual resource management, not memory management.
C++ uses its memory management for resource management, but Java doesn't. Java
improved resource management with "try with resources", but generally resource
management really isn't an issue for most Java developers. In modern
frameworks like Spring you rarely have to manage resources yourself. You let
the framework manage them for you, and the framework will provide them to you
via injection.

~~~
ErotemeObelus
I want a language where the garbage collector not only frees inaccessible
dynamically allocated blocks, but also frees all resources when they're
inaccessible. Is it possible to design such a generalized GC?

~~~
jarjarbinks455
In c# you can implement IDisposable. The garbage collector will call a dispose
method allowing you piggyback on the garbage collector for just about
anything.

But it's rarely a good idea to piggyback. Most resources are much more limited
or time sensitive than memory. So you should free them immediately.

Even when your resource - _is_ \- memory it sometimes is a very very very bad
idea to free via garbage collection.

~~~
ErotemeObelus
What is even the point of garbage collection? By the time you manage all the
resources of a 100k line application you're going to have to do as much work
as if you wrote it in C.

~~~
jarjarbinks455
Well the point of gc is to allow the algorithm to focus on the problem domain.
and not worry about mechanical implementation details of a computer.
Everything has a trade off. An obvious win still must pay a cost elsewhere. In
the case of GC it's simply not a good trade off for many resources. Sometimes
it cannot be used even if you were willing to accept a trade.

~~~
ErotemeObelus
Managing resources by hand __is __managing the mechanical implementation
details of a computer. So in order to have garbage collection that manages
more than just a sliver of memory so small that it counts as a rounding error
by the same you get to the size of real world projects, you need a custom
operating system and possibly even custom hardware too.

~~~
AnimalMuppet
Your statement is false for _many_ real world projects. (For some, you are
correct. Those projects should not be written in a garbage-collected language,
or should be written to run on a custom OS and custom hardware.)

------
brudgers
The "file" abstraction covers many different types of storage: spinning and
solid state disks, in-memory structures, whatever your cloud actually uses,
optical medial like DVD's, and even magnetic tape. Typically, these are
managed by the underlying operating system's IO interface not Java itself.

Historically, operating systems use buffers for IO and closing the file
includes flushing the buffers of in-flight data (in addition to things like
deallocating pointers to files at the OS level). Without explicit instructions
the operating system doesn't know when a file is no longer in use.

A programming language/environment could open and close files on every read
and every write automatically. But it would entail overhead for operating
system calls to allocate/deallocate nodes in the file table. For some types of
programs this might be ok. For others it might be problematic, particularly
those with moderate or strong dependence on IO.

~~~
ErotemeObelus
So in order to have complete automatic resource management you need to build a
custom OS and possibly even custom hardware.

~~~
codegladiator
How would your new OS/hardware know when the "use" of the resource is complete
? Maybe the dev wanted to read just 10 bytes from a 1 GB file, maybe 100
bytes... maybe its a telnet connection which is never supposed to be closed
and just kept in a pool ?

For a very small benefit of "automatic closing of resources" this looks like a
huge trade-off.

~~~
ErotemeObelus
Disagree that it is a small benefit. Resource management becomes so unwieldly
that there's little difference between a 100k line application in Java and a
100k line application in C with regards to memory/resource management. Are you
saying that moving beyond C is a "small benefit"?

And it's easy to determine when the use of the resource is complete: when
there are no active pointers to the resource (the circular reference problem I
don't think can happen with external resources like files).

~~~
pmontra
Some languages (Python, Ruby, probably dozens of others) have constructs along
these lines

    
    
      with f = open("data.txt")
        print f.readline()
    

The file is automatically closed at the end of the block. Those languages also
have explicit open/close/seek calls to let the developer implement more
complex cases.

Btw, the os closes any open file when the program ends.

~~~
ErotemeObelus
Yes, you're correct that os's have some kind of rudimentary reference counting
for files, but it's very inchoate and not designed as the __primary __method
of handling file references.

------
frou_dh
That's what the concept of "Finalizers" is for. They indicate that something
should be done to an object just before the runtime garbage collects it.

[https://en.wikipedia.org/wiki/Finalizer](https://en.wikipedia.org/wiki/Finalizer)

Files specifically are a bit thorny because the OS generally places a limit on
how many simultaneous open files a process can have, and you don't want to
risk bumping in to that limit due to unpredictable garbage collection timing.

