|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> Backwards compatibility is pretty evil, eh? ;-)
haskell still to get its own historic warts... :)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/03/2012 17:49, clipka wrote:
> Am 14.03.2012 18:09, schrieb Warp:
>> clipka<ano### [at] anonymousorg> wrote:
>>> If a GC implementation doesn't track free blocks, how is it ever going
>>> to re-allocate them to anything?
>>
>> A naive implementation of that would be:
>> [...]
>
>
> Well, I wasn't actually considering approaches that would be
> prohibitively inefficient :-P
That's actually how Haskell's GC works. :-P
(Or rather, it is if you select 1-space. The default is 2-space. In
other words, it allocates twice as much RAM as it actually needs. When
one half fills, it copies everything to the other half. More RAM, but
less processor time...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/03/2012 16:51, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> The GC engine needs to know quite a bit about the objects it's scanning
>> - how big they are, where their pointer fields are, etc.
>
> Exactly how does the GC engine know how large a block of allocated
> memory is? Where is this information stored?
Usually the object's class tells you that. You already have a vtable or
similar structure. (At least, you do in languages where /everything/ is
dynamically bound by default.)
> Also, if objects are transparently movable in memory without breaking
> the references pointing to them, that means that in addition to the
> reference the actual raw memory address of the object has to also be
> stored somewhere. Where is this information stored?
Depends on the implementation.
Smalltalk does it by adding a layer of indirection. The address of every
object in the system is held in a giant "object table". All objects are
referred to be object IDs, which are merely indices into this table. To
move an object, merely update its object table entry. (You can also
store auxiliary information here - e.g., if you wanted to /lock/ the
object while it's being moved.)
How Haskell does it is to copy each object from its old location to its
new location, and then overwrite the old copy with a "hey, this is where
I moved this object to" reference. The GC engine then uses that to
update any references in other objects as it finds them.
> You can't avoid bookkeeping when you are allocating blocks of variable
> size.
Sure. At a minimum, you need to know the size of those blocks.
Realistically, you also need to know what they contain, or you can't
follow pointers. You probably need to know a little other stuff too.
Most of this information is per-class rather than per-object, however.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/03/2012 19:47, nemesis wrote:
> Invisible escreveu:
>> Backwards compatibility is pretty evil, eh? ;-)
>
> haskell still to get its own historic warts... :)
Sadly, yes.
Although it /does/ have fewer than most languages. Then again, there's
less of it to start with, so I guess it would do.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/03/2012 18:58, nemesis wrote:
> it's everywhere, Andrew. Kinda like electricity: you just notice it when
> it goes down (and a huge call stack fills your browser).
Do you want to know... what... it... is?
The Matrix is everywhere. It is all around us. Even here, in this very
room. You can... feel it. When you walk across the street. When you go
to church. When you pay your taxes.
(Wait, what were we talking about?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/14/2012 2:26, Invisible wrote:
> pointlessly over-engineered,
The difference between enterprise software and other software is that
enterprise software is capable of being managed centrally. You can configure
it and maintain it and check its health while it's running, centrally,
without being there.
Do you get paged when your web server goes down? Can you configure how much
traffic has to dip before you get woken up at night? Can you get a list of
the people who are allowed to see a particular page? Can you track down
which ISP is at fault when the traffic to your site dips 20%? When serving
pages is slow, can you tell which part of the system is causing it? A bad
disk sector? A flakey network card?
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/14/2012 8:03, Invisible wrote:
> Heh, really? Most languages I work with can allocate new objects in O(1)
> time and using O(1) memory for bookkeeping. I'm not used to dynamic
> allocation being anything to worry about.
Yeah, it's the *de*allocation that takes a while.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/14/2012 9:24, clipka wrote:
> So far, so good. But how does the GC know how long each chunk of
> garbage-to-collect is?
It's using basically the same kind of information that's already in each
object to point to a vtable. If the first word of each object points to a
vtable, you stick the information once in the vtable about how big it is and
where the pointers are.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/14/2012 15:34, Orchid Win7 v1 wrote:
> merely update its object table entry.
This is also important for the "becomes" operator.
In Smalltalk, if you have an array X of size 10 that you now want to be size
20, you can do something essentialy like this:
y := a new array of size 20.
copy first ten elements of x into y.
x becomes y
That last statement swaps the variables x and y, so that all former
references to x now point to y and vice versa. It's how smalltalk does the
equivalent of std::vector without actually having a header object and a
content object.
I've nver seen any other language do that.
> Most of this information is per-class rather than per-object, however.
And I suspect if your language is sufficiently strongly typed, you could
figure out the classes of non-variant data without having to add information
to the instances.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/14/2012 2:55, Invisible wrote:
> to know whether the libraries eventually settled down and they stopped doing
> crap like this, or... ?
Both those are deprecated now."
> to make it easy for people to write code for your platform and only your
> platform. >:-D
I didn't say they had a generous reason for doing it. But it's exactly that
reason for why 90% of OSS is either targetting programmers or sucks. Usually
both. That which doesn't is paid for by a large company trying to displace
proprietary software.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |