On Tuesday, 13 September 2016 at 18:04:19 UTC, Jonathan M Davis
wrote:
On Tuesday, September 13, 2016 17:48:38 Laeeth Isharc via
Digitalmars-d wrote:
On Tuesday, 13 September 2016 at 11:59:46 UTC, Shachar Shemesh
wrote:
> On 13/09/16 02:21, deadalnix wrote:
>> I stay convinced that an hybrid approach is inevitable and
>> am
>> surprised
>> why few are going there (hello PHP, here right).
>
> Here's my worries about the hybrid approach. The GC run time
> is proportional not to the amount of memory you manage with
> the GC, but to the amount of memory that might hold a
> pointer to a GC managed memory. In other words, if most of
> my memory is RC managed, but some of it is GC, I pay the
> price of both memory manager on most of my memory.
>
> Shachar
Hi Shachar.
I hope you're well.
Would you mind elaborating a bit on why the cost of GC managed
memory is as high as you imply when combined with other
approaches, at least on a 64 bit machine and presuming you
have a degree of hygiene and don't directly use a pointer
allowed to point to either. Eg if you use GC for long lived
allocations and RC for short lived ones (and the RC
constructor makes sure the thing is not registered with the GC
so that takes care of short lived parts of long lived
structures), how in practice would this be a problem ? I am
no GC expert, but keen to update my mental model.
As I understand it, the problem is that the length of time that
the GC scan takes - and therefore that the world is stopped -
depends on how much memory it has to scan, not on how much
memory has been allocated by the GC. In many cases, that's just
the GC heap plus the stack, but if you're malloc-ing memory,
and that memory can hold references to GC-allocated memory,
then you have to tell the GC to scan that memory too in order
to avoid having anything it references being prematurely
collected. So, ultimately, how expensive the GC is in terms of
performance generally depends on how much memory can hold
referencs to GC-allocated objects and not how many such objects
there are, meaning that avoiding allocating with the GC in a
lot of your code doesn't necessarily save you from the
performance cost of the GC. To avoid that cost, you'd need to
either not have many places in malloc-ed memory which could
refer to GC-allocated memory, or you'd need to write your code
in a way that the it was guaranteed that the GC-allocated
objects that were referenced in malloc-ed memory would have
other references in memory that was scanned that lived longer
htan the malloc-ed memory so that the malloc-ed memory wouldn't
need to be scanned (which is quite possible in some
circumstances but potentially risky).
Using a 64-bit system significantly reduces the risk of false
pointers, but it doesn't reduce the amount of memory that
actually needs to be scanned. And whether using the GC for
long-lived allocations and RC for short-lived ones would help
would depend primarily on how many such objects would be
around at any one time - and of course, whether they refer to
GC-allocated memory and would thus need to be scanned. But
reducing the amount of memory that the GC needs to scan and
reduce how much is GC-allocated are two separate - albeit
related - problems.
- Jonathan M Davis
Thanks you for the clear explanation. So if you don't have GC
allocations within RC structures and pick one or the other, then
the concern does not apply?
