Re:Securing tomorrow's software: the need for memory safety ...
by pizlonator on Sunday March 02, 2025 @05:48PM
(#43236097)
Pretty much everything you're saying is true.
> It's not widely known, and it seems to be still in the research stage.
Yes on both counts.
> A lot of things in this area never really get out of that.
I hope that doesn't happen to Fil-C, but it could!
> Getting these things to mass deployment, ticking all those little boxes, is a lot of effort.
100%
I think this is one area where I'm trying to make Fil-C different than what came before it. I'm trying to tick all those little boxes. It's a lot of work!
> Porting a distribution to a new CPU architecture is likely easier, especially after the early stages (toolchain bringup).
Not sure about this. It might be true today because Fil-C hasn't yet ticked all the boxes, but the aim is definitely to be close to the cost of porting to a new CPU. It's already like that for a lot of code.
> Perhaps the memory overhead?
Heh yeah. The invisicaps cost memory. And GC costs memory.
> Or it might turn out that the desired performance characteristics basically require a JIT that specializes code so that typed pointers can be used where the types are known to be correct.
I've thought about how a JIT might help. I don't think it would. (Most of my compiler experience is writing JITs and I wrote JavaScriptCore's JITs, so I'm biased towards seeing JIT opt opportunities - and I don't see any in Fil-C right now.)
> It's not widely known, and it seems to be still in the research stage.
Yes on both counts.
> A lot of things in this area never really get out of that.
I hope that doesn't happen to Fil-C, but it could!
> Getting these things to mass deployment, ticking all those little boxes, is a lot of effort.
100%
I think this is one area where I'm trying to make Fil-C different than what came before it. I'm trying to tick all those little boxes. It's a lot of work!
> Porting a distribution to a new CPU architecture is likely easier, especially after the early stages (toolchain bringup).
Not sure about this. It might be true today because Fil-C hasn't yet ticked all the boxes, but the aim is definitely to be close to the cost of porting to a new CPU. It's already like that for a lot of code.
> Perhaps the memory overhead?
Heh yeah. The invisicaps cost memory. And GC costs memory.
> Or it might turn out that the desired performance characteristics basically require a JIT that specializes code so that typed pointers can be used where the types are known to be correct.
I've thought about how a JIT might help. I don't think it would. (Most of my compiler experience is writing JITs and I wrote JavaScriptCore's JITs, so I'm biased towards seeing JIT opt opportunities - and I don't see any in Fil-C right now.)