3 ms·

I hope this GC will be able to signal deterministically when an object will be free, getting destructors in java would be quite nice for checks and resources cl

I hope this GC will be able to signal deterministically when an object will be free, getting destructors in java would be quite nice for checks and resources cleanups

chrisseaton 6y ago
Yikes I don't think anyone else wants this. Destructors (finalisers) are seen as a pretty terrible mistake in Java. There is a better replacement that is reference queues, but I think you want to think extremely hard before using those as well. And no serious GC is going to be able to signal it deterministically! In Java you should really manually clean up external resources. Trying to get the GC to do it for you is never going to end well. The GC doesn't guarantee to free any object at all.
- The_rationalist 6y ago
  are seen as a pretty terrible mistake in Java because of the limitation it has with current GC. Having a method deterministically being called before being freed is a feature that increase language expressiveness and that has no inherent downside. So yes many devs would want that and you have failed to say a reason for a dev to be "against" said feature. In Java you should really manually clean up external resources. this is nuisible work that should be automated and allow an error class that shouldn't exist (e.g forgetting to close a file descriptor) How can this make sense to you? Things to say: Java already has autocloseable which cover in big part the needs of a destructor. It's just that it can't be used (I believe) for logging or behavior, only for resource closing which limit expressiveness and observability. And no serious GC is going to be able to signal it deterministically yes this limitation is shared by all current GCs hence my point on a future GC. The linked article make deterministic something that weren't before so my comment is not HS. The GC doesn't guarantee to free any object at all. If this is universal to all GCs that exists and that will ever exists? Then how does autocloseable work? reference queues what is the difference with weak pointers?
  - chrisseaton 6y ago
    > you have failed to say a reason for a dev to be "against" said feature Because as a developer I know we don't know how to implement it in a safe reliable way. I want to write safe reliable code so I don't want to use this feature. > The linked article make deterministic something that weren't before so my comment is not HS. That's not what the article means by 'deterministic', I'm afraid. They're talking about it being deterministic at some point where the object is moved to. It doesn't make anything temporally more deterministic. > If this is universal to all GCs that exists and that will ever exists I think it's pretty fair to say that nobody in the industry knows how to make a reasonably high performance moving GC that is deterministic in when it frees objects. Maybe someone will invent one one day? I wouldn't hold my breath. > Then how does autocloseable work? Something important to know is that AutoClosable has nothing at all to do with the GC, so disregard that for this discussion. It just adds some code to be called after a lexical block. It doesn't know anything about whether the object is live or not. > what is the difference with weak pointers? Sorry not sure what this is asking - what is the difference between weak pointers and... what? Reference queues are at least in-band and run under programmer control, but they're still non-deterministic in when (if!) a reference will be pushed to the queue.
  - koreth1 6y ago
    Relying on GC to clean up finite resources such as open file descriptors is a risky idea because you can run out of file descriptors or other resources in between GC invocations. You absolutely can use AutoCloseable for things like logging. SLF4J, for example, provides MDC.putCloseable() which is designed to be used in a try-with-resources block. As for how AutoCloseable works: try (SomeAutoCloseableObject thing = SomeClass.someMethod()) { ... } is effectively just syntactic shorthand for SomeAutoCloseableObject thing = SomeClass.someMethod(); try { ... } finally { thing.close(); } That's it. There's no GC magic involved; it just calls "close" which is just an ordinary method that can have any arbitrary code in it. (I should add: try-with-resources isn't EXACTLY equivalent to the second example. But it's close enough for purposes of explanation.) The official docs explain it in more detail with more examples: https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html https://docs.oracle.com/javase/tutorial/essential/exceptions...

I hope this GC will be able to signal deterministically when an object will be free, getting destructors in java would be quite nice for checks and resources cleanups

chrisseaton 6y ago

Yikes I don't think anyone else wants this. Destructors (finalisers) are seen as a pretty terrible mistake in Java. There is a better replacement that is reference queues, but I think you want to think extremely hard before using those as well. And no serious GC is going to be able to signal it deterministically! In Java you should really manually clean up external resources. Trying to get the GC to do it for you is never going to end well. The GC doesn't guarantee to free any object at all.

The_rationalist 6y ago
are seen as a pretty terrible mistake in Java because of the limitation it has with current GC. Having a method deterministically being called before being freed is a feature that increase language expressiveness and that has no inherent downside. So yes many devs would want that and you have failed to say a reason for a dev to be "against" said feature. In Java you should really manually clean up external resources. this is nuisible work that should be automated and allow an error class that shouldn't exist (e.g forgetting to close a file descriptor) How can this make sense to you? Things to say: Java already has autocloseable which cover in big part the needs of a destructor. It's just that it can't be used (I believe) for logging or behavior, only for resource closing which limit expressiveness and observability. And no serious GC is going to be able to signal it deterministically yes this limitation is shared by all current GCs hence my point on a future GC. The linked article make deterministic something that weren't before so my comment is not HS. The GC doesn't guarantee to free any object at all. If this is universal to all GCs that exists and that will ever exists? Then how does autocloseable work? reference queues what is the difference with weak pointers?
- chrisseaton 6y ago
  > you have failed to say a reason for a dev to be "against" said feature Because as a developer I know we don't know how to implement it in a safe reliable way. I want to write safe reliable code so I don't want to use this feature. > The linked article make deterministic something that weren't before so my comment is not HS. That's not what the article means by 'deterministic', I'm afraid. They're talking about it being deterministic at some point where the object is moved to. It doesn't make anything temporally more deterministic. > If this is universal to all GCs that exists and that will ever exists I think it's pretty fair to say that nobody in the industry knows how to make a reasonably high performance moving GC that is deterministic in when it frees objects. Maybe someone will invent one one day? I wouldn't hold my breath. > Then how does autocloseable work? Something important to know is that AutoClosable has nothing at all to do with the GC, so disregard that for this discussion. It just adds some code to be called after a lexical block. It doesn't know anything about whether the object is live or not. > what is the difference with weak pointers? Sorry not sure what this is asking - what is the difference between weak pointers and... what? Reference queues are at least in-band and run under programmer control, but they're still non-deterministic in when (if!) a reference will be pushed to the queue.
- koreth1 6y ago
  Relying on GC to clean up finite resources such as open file descriptors is a risky idea because you can run out of file descriptors or other resources in between GC invocations. You absolutely can use AutoCloseable for things like logging. SLF4J, for example, provides MDC.putCloseable() which is designed to be used in a try-with-resources block. As for how AutoCloseable works: try (SomeAutoCloseableObject thing = SomeClass.someMethod()) { ... } is effectively just syntactic shorthand for SomeAutoCloseableObject thing = SomeClass.someMethod(); try { ... } finally { thing.close(); } That's it. There's no GC magic involved; it just calls "close" which is just an ordinary method that can have any arbitrary code in it. (I should add: try-with-resources isn't EXACTLY equivalent to the second example. But it's close enough for purposes of explanation.) The official docs explain it in more detail with more examples: https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html https://docs.oracle.com/javase/tutorial/essential/exceptions...