On Wednesday, 14 September 2016 at 06:33:59 UTC, Shachar Shemesh
wrote:
On 14/09/16 09:05, Walter Bright wrote:
On 9/13/2016 10:38 PM, Shachar Shemesh wrote:
But if you do want to allow it, then my original problem
comes back.
You have to
scan the malloced memory because you are not sure where that
memory might
contain pointers to GC managed memory.
If mallocing for types that are statically known at compile
time, it
should be knowable if they need scanning or not.
I believe you are under the assumption that structs will not be
GC allocated. I don't think it is a good assumption to make.
Even if it is, however:
struct SomeStruct {
string something;
}
Please let me know if scanning this struct for GC pointers is
necessary or not. Also, even if this is knowable, I'm not sure
how you are suggesting we mange it.
The only practical approach I see is that if any RC managed
memory might contain pointers to GC managed memory, then all RC
managed memory needs to be scanned (unless you think the
compiler can help out with that).
Shachar
In D code that I have read where people use RC types they have
different names making it quite clear - eg RCString.but
If you're worrying about GC presumably you have a decent size
problem anyway (and I admire the ambition of weka in this
respect). So then seems to me that yes, there is a tax in
writing code that uses the language in a way that a minority of D
users are using it in. The generation after the pioneers, if
they avoid the arrows of the prior generation, at least have a
lot more hard work than subsequent generations. But on the
other hand it is a package deal, and initial costs amortise.
How would you end up with a GC allocated struct by mistake
(presuming you think it through first) at the size you are at?
200k lines and 30 people is a lot, but it's also not Windows
scale. And if you did, and it mattered, wouldn't you pick it
up quickly with GC profiling?
