Potential Garbage Collection issue with Generics
Closed this issue · 4 comments
While garbage-collection can ultimately be deferred in the code-gen of a procedure that requires generic-type-parameters, it cannot be done for records/structs that have generic-type-parameters.
The proposed solution would be to analyze inputted type arguments, which are ultimately all non-generic, and configure garbage collection trace settings based off of them.
There may be a larger issue surrounding generics in general - it's impossible to determine with any certainty, at compile time - and perform runtime-garbage collection on generics because it's impossible to determine whether the generic is or isn't a reference type - which tells the garbage collector to either trace it, it's children, some of it's children, or completely forgo garbage collection tracing.
While it's possible to do this with generic type arguments passed into record/struct allocators, as done in the last commit, passing in another generic which is dependent on on the reference tracing capabilities of the generic-type-argument within the frame of the current context.
My proposed fix would be to be to add another opcode that allows the virtual-machine to configure garbage collection trace statuses from register values, and append "silent" trace-status parameters for generics.
The downsides:
- Extra runtime computation can slow a program down significantly, especially if the code segment is used a lot.
- Extra memory because this requires more registers to be allocated for every procedure that defines generic type arguments.
- Adds complexity to an already-complex virtual machine. Complicating the garbage collector may hamper future efforts to implement just-in-time compilation.
The upsides:
- Well, it works and does garbage collection correctly on generics, instead of simply treating them as primitive types and foregoing garbage collection.
Another realization dawned upon me ... because you cant initialize new generics, that means there isn't any need to do garbage collection configuration on any generic, except for values that have these generics as children.
This has been fixed in the previous commit.