 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> The other fun thing is that few people have built concurrent GC engines.
> At least with manual memory management, one thread doesn't usually block
> other threads from running.
A concurrent compacting GC sounds to me like a very hard problem.
If the GC moves objects around in RAM, it has to make sure that no code
is modifying the object while the GC is moving it. How does it achieve
that efficiently, I have no idea.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15/03/2012 02:42 PM, Warp wrote:
> A concurrent compacting GC sounds to me like a very hard problem.
Everybody seems to think they know how it could be done... and yet,
nobody has written the code that does it.
> If the GC moves objects around in RAM, it has to make sure that no code
> is modifying the object while the GC is moving it. How does it achieve
> that efficiently, I have no idea.
Well, Haskell currently does thinks like have a separate heap for each
processor core. But that doesn't guarantee there are no pointers from
one heap to another, so you still gotta be careful. What you would
probably do is "mark" each object somehow, before you go about moving
it. Trouble is, that adds the overhead of testing whether each object is
marked every single time you want to access any object...
I'm sure it can be implemented somehow. The question is how complicated
it would be, and how much overhead it would add.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.03.2012 15:42, schrieb Warp:
> Invisible<voi### [at] devnull> wrote:
>> The other fun thing is that few people have built concurrent GC engines.
>> At least with manual memory management, one thread doesn't usually block
>> other threads from running.
>
> A concurrent compacting GC sounds to me like a very hard problem.
> If the GC moves objects around in RAM, it has to make sure that no code
> is modifying the object while the GC is moving it. How does it achieve
> that efficiently, I have no idea.
If the GC was part of the OS, maybe something could be done with page
faulting.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15/03/2012 04:14 PM, clipka wrote:
> If the GC was part of the OS, maybe something could be done with page
> faulting.
Indeed. Darren found a paper about this very idea a while back. Some
guys patched the Linux kernel to do interesting stuff in this direction.
And of course, if GC was in the OS, then you wouldn't have this
situation of "the GC engine for program X isn't actually using this RAM
right now, but because it's reserved it from the OS, the GC engine for
program Y can't use it"...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/15/2012 2:09, Invisible wrote:
> least with manual memory management, one thread doesn't usually block other
> threads from running.
You would be surprised at the number of implementations of malloc() and
free() that assume you're single-threaded and require locks.
Also, in a language that supports threads in the first place (like Erlang),
the heaps are per-thread, so that's OK.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/15/2012 9:20, Invisible wrote:
> And of course, if GC was in the OS, then you wouldn't have this situation of
You also wouldn't need finalizers.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/15/2012 7:42, Warp wrote:
> A concurrent compacting GC sounds to me like a very hard problem.
Yes.
> If the GC moves objects around in RAM, it has to make sure that no code
> is modifying the object while the GC is moving it. How does it achieve
> that efficiently, I have no idea.
You wind up dividing the heap into multiple zones, based on whether you've
scanned the object, compacted the object, or haven't looked at the object.
If someone tries to write to an object you've scanned and assign it a
pointer to an object you haven't scanned, then at that point you move the
object from the unscanned to the scanned region.
If you set it up so writes cause page faults in that situation, you can get
really good performance by just GCing one page worth of objects each time
you hit that fault, which is the paper Andrew refers to.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15/03/2012 11:17 PM, Darren New wrote:
> On 3/15/2012 9:20, Invisible wrote:
>> And of course, if GC was in the OS, then you wouldn't have this
>> situation of
>
> You also wouldn't need finalizers.
Yeah you would. The OS doesn't magically "know" that a specific object
is holding a specific external resource.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> You would be surprised at the number of implementations of malloc() and
> free() that assume you're single-threaded and require locks.
Care to give an example (in a modern OS)? At least Gnu libc uses locking
malloc() and free() (and it's one of the reasons for their slowness).
Quite many multithreaded programs would break if malloc() and free()
were not thread-safe.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/16/2012 1:52, Invisible wrote:
> On 15/03/2012 11:17 PM, Darren New wrote:
>> On 3/15/2012 9:20, Invisible wrote:
>>> And of course, if GC was in the OS, then you wouldn't have this
>>> situation of
>>
>> You also wouldn't need finalizers.
>
> Yeah you would. The OS doesn't magically "know" that a specific object is
> holding a specific external resource.
If your OS is garbage-collected, it's not an "external" resource, now is it?
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
