On Friday, 14 February 2014 at 09:01:09 UTC, tcak wrote:
On Friday, 14 February 2014 at 04:41:43 UTC, Jerry wrote:
Hi all,
I just had the following thought on limiting the gc in regions.
I don't
know if this would address some of Manu's concerns, but here
goes:
My thought is to have something like the following:
GC.track();
auto obj = allocateStuff();
GC.cleanup(obj);
The idea here is that track() tells GC to explicitly track all
objects
created from that point until the cleanup call. The cleanup()
call
tells gc to limit its collection to those objects allocated
since the
track() call. The obj parameter tells gc to consider obj live.
This way, you can avoid tracking everything that may get
created, but
you can limit how much work gets done.
Comments? Slams?
Jerry
A programmer's aim is to tell computer what to do. Purpose of
GC is to help him to prevent problems. In default, AFAIK, GC
considers every part of memory in case there are references in
them. Well, if the time taking process is scanning all memory,
programmer could tell to GC, if he/she trusts about
correctness, not to scan some parts of memory to limit scanning
area. Example, if I create a char array of 10,000 items, why
would I want GC to scan it. I won't put any object references
in it for sure.
This only works when you are the only guy on the team and have a
small codebase to visualize on your head.
The moment a middle size team comes into play, it is chaos.
There is a reason why manual memory managed languages have lost
their place on the enterprise.
--
Paulo
