 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/16/2012 4:41, Warp wrote:
> 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).
I think you just answered the question.
Maybe I phrased my statement wrong. Lots of implementations of malloc() and
free() share a heap amongst multiple threads, so either need to lock
internally or need to be used from a single-threaded system. And hence, they
assume you're single threaded within the context of malloc/free because
they've acquired a global lock. I.e., yes, you get contention between
threads with manual memory management.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> 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?
I think that the idea was that RAM is not the only resource that an
object could own, and having to manually free such resource is error-prone
and going back to the days of C programming.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/16/2012 11:39, Warp wrote:
> I think that the idea was that RAM is not the only resource that an
> object could own, and having to manually free such resource is error-prone
> and going back to the days of C programming.
Right. In a GCed operating system, why would you own anything other than
GCed resources? You don't need file handles. You don't need IPC ports. You
don't need window handles. Etc. Look at Smalltalk - nothing had finalizers,
because it had its own OS. Or Hermes. Or Eros. (Eros and Hermes, for
example, treats all your disk space as just one big virtual memory address
space. There's no files. You just store data in your variables, and serve
them over IPC ports.)
About the only thing you'd need is some way of closing a socket when the
connection got GCed, in which case you could have a process that closes the
socket when its local IPC connections all get closed, and you just talk
through that process. That's basically how Erlang manages it.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Right. In a GCed operating system, why would you own anything other than
> GCed resources?
I think you are talking about system resources. A program may use other
resources than simply system resources. If objects are never finalized,
how exactly are you going to free those resources? Manually?
Even then, sometimes even *memory* handling could require finalizers.
The quintessential example would be if you wanted to implement a
copy-on-write mechanism. In this case you need to "retain" and "release"
a reference counter each time an object takes hold of or drops a shared
block of memory. Without finalizers it becomes difficult.
You could have manual "retains" and "release" calls, but then we are
back to square one, ie. manual memory management, which is laborious and
error-prone, and hard to make exception-safe.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/16/2012 12:38, Warp wrote:
> I think you are talking about system resources. A program may use other
> resources than simply system resources.
Like what?
> The quintessential example would be if you wanted to implement a
> copy-on-write mechanism.
That hasn't anything to do with finalizers. In advanced systems, that sort
of stuff isn't something you write in the application code, either, any more
than worrying about taking things out of the B-tree is something a SQL
programmer worries about when deleting a row.
And yes, at IBM, when they were working in NIL (the precursor to Hermes),
they ported a large and complex system from a single machine implementation
to run on a distributed hot-failover cluster changing nothing but the
compiler, just like you could with SQL code.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
