-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can we get rid of garbage collection? #4
Comments
As EO(L) will be compiled into Java lang then why garbage collection question was raised at all? |
@Englishman we can compile into Java code with only static methods, no objects. There will be no garbage collection in this case. |
@Englishman and Java won't be the only target platform. we will compile to other platforms too, but later (C, maybe Assembly directly, etc) |
How would all objects being immutable relate to garbage collection? Aren't objects still being retained in memory until they cease to be needed? Are you proposing developers manually cleanup their objects again? |
In case all objects are immutable, the garbage collection seems to be unnecessary, because:
|
@gukoff this is exactly behavior (all you wrote) in Object Pascal — and I liked. |
Here, the first statement is the most important. I guess, not all the objects are immutable in Object Pascal; does every circular dependency lead to a memory leak there? |
@gukoff the objects in Object Pascal are the same that Java: They are mutable by default. Your code will make them immutable. PS: I have a blog that talks about truly object-oriented programming using Object Pascal. |
If all objects would live on the stack, then there is no need for GC, just reference counting. However then you would want to have tail recursion so you can shorten the stack - tail recursion on the JVM stack is a bit tricky. |
BTW. if someone is not familiar with details of Garbage Collection and Reference Counting approaches (like myself until recently), I'm recommending this short podcast: |
I do not understand the issue. Please correct me if I'm wrong with my assumptions.
Option Option It might be just a matter of preference, however it seems like leveraging existing GC 'infrastructures' is going to save a lot of effort. I personally am practically certain that I'm not going to use any language that requires manual GC under any circumstances. |
@gukoff Isn't reference counting a kind of garbage collection? |
You are right, it is. What I meant is the non-deterministic garbage collection. |
@interstar I think yes - both tracing garbage collection and reference counting are forms of garbage collection. What they probably mean is that they want to avoid tracing GC (e.g. mark-and-sweep). @gukoff, this is a fascinating idea! However, if you truly want no cycles, you have to forbid anything that might semantically appear "simultaneous", for example the bit of Haskell code in https://wiki.haskell.org/Tying_the_Knot :
Note that even though no mutable values were used, there's still a cycle. Does this make sense? Or is this irrelevant given the rest of the language? |
with all due respect you should will be set muttable objects(Sooner or later), because some objects have different states. |
Surely this would be unworkable (working against the platform) as the JVM platform implements it's own GC? (so you'll be GC'd anyway) |
@gukoff: you can have circular dependencies with reference counting, as long as one is the owner - see https://doc.rust-lang.org/book/ownership.html |
Speaking of Rust, we could employ a similar borrow checking model with lifetimes. I.e. have three primitive access modes:
Obviously the references must not outlive the owned object or underlying stack, hence we’ll need some sort of lifetime tracking for this. More complex references (including automatic reference counting and garbage collection when necessary) can be implemented through trait/aspect contracts which allow automatic conversion to one of the primitive reference types. Not sure if it makes sense to use references for cloneable types, since clones have the same identity anyway. As an alternative, we could provide aspect contracts which determine whether the type supports copying instead of moving, or creating temporary Views with lifetime guards, and whether the moving/copying of the type and/or its Views can occur across concurrent jobs. An owned object moved to a method can be consumed (disposed of) by it, becoming no longer accessible. If the method returns a new object implementing the same contract(s), the compiler can basically translate that to a machine code operation over mutable memory, eliminating the overhead for us. If we really need a “writable memory” object (i.e. for low level state tracking), we can use one of the Cell types for that. Writes to a safe Cell by shared references (or Views) must be gated behind a mutex/spinlock mechanism, failable nonblocking attempts and/or exceptions. Cloneable cells can be implemented as copy-on-write. See also https://www.reddit.com/r/rust/comments/25ma77/an_alternative_take_on_memory_safety/ |
Reference counting is a garbage collection technique
If you compile EO code into java source code files there it would be no way to destruct an object.
it is not objective |
This is outside of EO scope, I believe. The destination platform (JVM or such) will deal with objects the way they want. |
Can we get rid of garbage collection? Is it technically possible? If all objects are immutable, I think it is...
The text was updated successfully, but these errors were encountered: