![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/14/2012 8:52, Warp wrote:
> And btw, cyclic references are not the only problematic situation with
> reference counting. There are cases where objects may be deleted too early,
> while there's still code using them.
And your references have to be as big as your address space, approximately.
Smalltalk back in the 64K days used a 5-bit reference count. If you ever had
more than 30 references, it just wouldn't get collected until the mark/sweep
collector ran.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/14/2012 10:10, clipka wrote:
> Then again, how would any other GC prevent this kind of thing happening?
Because real GC engines count references on the stack. The very fact that A
is going to return to a member function of B is enough to keep it live.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/14/2012 10:52, clipka wrote:
> But doesn't the "this-pointer tracking" in a reference-tracking GC approach
> incur approximately that very same penalty?
No, because it's not counting references. The efficiency of GC over RC is to
a large extent the elimination of updating something every time you assign a
pointer. The GC runs, sees a reference to B on the stack, and avoids
discarding B. C++ programs don't have access to the stack per se, so they
can't do that sort of thing.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/14/2012 8:37, Invisible wrote:
> Um... So how is the pro version actually different from VS Express?
Some of them include a bunch of stuff you don't need if you're only working
by yourself, for example.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 15/03/2012 03:40 AM, Darren New wrote:
> 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.
...but not as long as figuring out /what/ to deallocate. ;-)
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.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |