←back to thread

597 points pizlonator | 2 comments | | HN request time: 0.057s | source
Show context
pcfwik ◴[] No.45134476[source]
Given the goal is to work with existing C programs (which already have free(...) calls "carefully" placed), and you're already keeping separate bounds info for every pointer, I wonder why you chose to go with a full GC rather than lock-and-key style temporal checking[1]? The latter would make memory usage more predictable and avoid the performance overhead and scheduling headaches of a GC.

Perhaps storing the key would take too much space, or checking it would take too much time, or storing it would cause race condition issues in a multithreaded setting?

[1] https://acg.cis.upenn.edu/papers/ismm10_cets.pdf

replies(2): >>45134484 #>>45134487 #
1. pizlonator ◴[] No.45134484[source]
I think the lock and key approaches don’t have Fil-C’s niftiest property: the capability model is totally thread safe and doesn’t require fancy atomics or locking in common cases
replies(1): >>45134503 #
2. pcfwik ◴[] No.45134503[source]
makes sense, thanks --- cool project!