Sooooo... what you're saying is that you want fully-auto GC for when it makes sense, and the option of dropping out of it when it doesn't.
Which is *PRECISELY* my position. Your articles seem to press for auto-GC 24/7, because hey, the hardware will catch up.
Eventually, "saftey by default" (as I call it in the article) will be the minimum standard. In part 2 I talk about dropping down to lower-levels, specifically how it's too easy in Obj-C. (Arguably, you're always at a lower-level in Obj-C since even "objects" involve thinly disguised and generally unprotected pointers. It's a long way from "managed code" in the Java/CLR style.)
Quote:
Sure, the history of programming abstractions is a punctuated equilibrium model, and is very likely that hardware will provide speed boosts greater than the plateaus in the model, but if you look at the spikes, hardware, historically, can't keep up. It catches up, and then the next evolution occurs, and blammo.
Sun (with Java) and MS are doing "saftey by default" today and don't seem to be going out of business because of it. (Okay, we'll see about Sun ;-) Look at it this way: worst case, we still have more abstraction than exists today (Obj-C vs. "managed code") and things go faster. Yes, there will always be the next big thing to suck resources, but the "dotted line" I mention in my article between stuff that's "nice, but too slow" and stuff that's ready to be used in real applications inevitably rises.
Quote:
Maybe, when that day comes, a default of auto-GC will be the best approach
I'm sure you'll find a lot of Java, C#, Python, Ruby, Lisp, etc. programmers who will argue that that day has already come
Quote:
but until that day comes, and until the precise semantics of the various object management schemes can be captured and enforced systematically, I will continue to have the opinion that auto-GC is an important tool, but one that cannot be pushed as a universal solution.
I think your viewpoint is a bit too constrained. Plenty of real, useful apps can be developed and shipped without ever really "solving" (in the rigorous sense) any of the stuff you're researching. The industry is already getting by with "good enough" in many cases, and I expect it will continue to do so.
I love it when Mr. Siracusa shows up, and suddenly a lot of tails are tucked between people's legs.
It pays to keep your rhetoric under control--because you get called on it, when you least expect it.
I just see Siracusa trying to hold onto his position and not doing particularly well. He is having to revert to a "My Defined Future" is where the problem is. The only problem is it's obvious fron the comments on his articles and here that those with brains switched on don't buy his future as being the most likely one. Hence his negative points, while seemingly supporteby accurate lower level technical details, become quite excessively brittle when faced with higher level "Non-Siracusa Defined Future" reality.
You seem to be assuming that I don't know that C# and Java use forms of garbage collection. I'm not sure where you got that idea. When I called Obj-C with GC a "half-solution," I meant that it is an attempt to have your cake and eat it too, so to speak, much like Copland was.
IOW, it's an attempt to add a feature to an existing technology where it may not fit in well and where it doesn't really solve the problem completely (e.g., Copland's plan to add MP/PMT to Mac OS while still allowing some processes to run "unprotected") instead of cutting the Gordian knot by pushing the old ways off to the side in favor of a (relatively) clean slate (e.g., Mac OS X's design with its BSD base, Cocoa, and the classic environment for backward compatibility, which allowed Carbon to abandon the worst of the cruft and break compatibility where necessary)
In part 2 you can read more about why I think Obj-C with GC is not an adequate solution in the long run.
I also talk more about performance issues in part 2.
Well, I don't see any meaningful mention of performance issues. And you only argument that isn't contrived is that pointers/direct address manipulation isn't hidden in Obj-C compared to Java or unlocked like C#. While that is true on it's own it is hardly the fault to doom an operating system API and by association the entire operating system platform, ala Copeland. And it totally ignores the poionts I made unless you are counting your incorrect statement: "Despite the performance hit, increased abstraction always wins in the end because it makes humans more efficient. This has happened time and time again in the PC industry, and it will happen as long as computing power continues to increase." That is hardly a universal truth.
Increased abstraction has it's place, but enforced pure abstraction of the type you are campaigning for and stating is a requirement is not an acceptable answer for anything which requires time critical computing. The perfect general solution exists nowhere, not even in the languages you cite. Damning another is hardly going to fix anything, and doesn't make the other languages any better.
Quote:
That's an interesting statement from someone who began his post with "Siracusa is an ignorant blowhard"
Not really, although I do see the touch of irony. The typical Arsian flame war begins with strategic culling of context. Something you are guilty of here. The next sentence read: "It got too popular and is now becoming too polarized by more and more opinionated reporting and the Battlefront is everywhere, not just the Battlefront."
I also put in the disclaimer to let others know I am biased against Ars for the stated reasons. Reasons that caused me to vote with my pocketbook. That's considered a common practice in journamism and opinion pieces throughout the mass communications media. So something done in fairness has become interesting? That's a sad stament on society and the state of bloggers in general.
Eventually, "saftey by default" (as I call it in the article) will be the minimum standard. In part 2 I talk about dropping down to lower-levels, specifically how it's too easy in Obj-C. (Arguably, you're always at a lower-level in Obj-C since even "objects" involve thinly disguised and generally unprotected pointers. It's a long way from "managed code" in the Java/CLR style.)
Yes, it is, and as I've been saying all along, I think Obj-C needs something better for object management. The current model is quite good, but the enforcement stinks. It's too easy to break.
Here's a fliparoonie for you: How about, instead of objects being specifically stated to be retained, they were retained by default, and needed to be specifically *not* retained? Would that make it more palatable to you? It's ref-counted GC by default, but easily escapable for when it needs to be. Your `safety by default', but with a thin veneer that's easily reached through.
Managed code is fine, when you can trust the manager to always be right, or sidestep them as necessary.
Quote:
Sun (with Java) and MS are doing "saftey by default" today and don't seem to be going out of business because of it.
I thought you *weren't* saying it would kill Apple...
And you're right, their products are being used by many - and shunned by many others due to the GC impact.
I program daily in Python, and while I love the GC during development, it turned out to have a much larger negative impact on runtime than I ever thought it would. Instead, I have the default GC turned off, and I trigger explicit culling runs at well-defined points in the execution. This is an excellent method for having control over the GC... something that I find lacking in Java, and something that I find incomprehensible to most programmers who are strong advocates of GC. "Why would you want to do that? The hardware will eventually catch up..."
This is *precisely* the sort of thing I'm talking about when I say that while GC is good, it's not universally good, and the current implementations are even less so. The developer *has* to be able to tell the runtime to stop the GC mucking about, or be able to control how it triggers, when it triggers, and how to handle pathological cases. Like I said, it's a tool, but the best tools are ones that aren't superglued to your hand.
Quote:
(Okay, we'll see about Sun ;-) Look at it this way: worst case, we still have more abstraction than exists today (Obj-C vs. "managed code") and things go faster.
Not to get bogged down in minutia here, but, are you stating that the managed code is faster than Obj-C? Or that things are faster now than they were in the past? I'm not entirely sure how to parse this sentence.
Quote:
Yes, there will always be the next big thing to suck resources, but the "dotted line" I mention in my article between stuff that's "nice, but too slow" and stuff that's ready to be used in real applications inevitably rises.
Sure it does, but you have to be careful not to weight that line down with too much baggage, or it won't rise fast *enough*.
Quote:
I'm sure you'll find a lot of Java, C#, Python, Ruby, Lisp, etc. programmers who will argue that that day has already come
*waves hand in air*
Yes, but then I matured as a Python programmer, and realized that it wasn't a universal panacea, and I am *SO* thankful that I can manually control the GC system... if I couldn't, Python wouldn't be a viable language for my development process.
Quote:
I think your viewpoint is a bit too constrained. Plenty of real, useful apps can be developed and shipped without ever really "solving" (in the rigorous sense) any of the stuff you're researching. The industry is already getting by with "good enough" in many cases, and I expect it will continue to do so.
And I think your viewpoint is a bit too hopeful. While plenty of real, useful apps *will* be developed and shipped using the current state of the art in GC, many more will suffer greatly if attempted using the same techniques. And then you have time being spent on figuring out how to get *around* the GC, how to encapsulate *that* behaviour, etc. There went some of that hard-won efficiency. \ `Good enough' is what led to Copland in the first place, if you recall. `Good enough' isn't, by your own example.
John, I don't think we're that far apart on this. I'm certainly not in the camp advocating that the current situation is just peachy keen. I'm coming at this from the *other* end, of someone who would dearly love to see much more abstraction than any language right now could even dream of handling... but sees that the core issues for developing solid support for those abstractions is predicated on getting object management conceptualized in all its facets, not swept under the rug. And given that the biggest rallying cry for GC has been, IMO, "You don't have to ever think about it", I see GC in its current incarnation in technology, and industry perception, as limiting, not enhancing, future abstraction. You're thinking 2010, I'm thinking 2020. I'd hate to see a stop-gap measure, in GC, cause yet another round of this, but on a far more important level of abstraction.
Because stop-gaps were what led to Copland in the first place, by your own assertion.
Here's a fliparoonie for you: How about, instead of objects being specifically stated to be retained, they were retained by default, and needed to be specifically *not* retained? Would that make it more palatable to you? It's ref-counted GC by default, but easily escapable for when it needs to be. Your `safety by default', but with a thin veneer that's easily reached through.
Yes. this could be done by making retain/autorelease a no-op. An object that is copied or alloced in Obj C has a retain count of one anyway. Objects that are autoreleased are zero retained, the the autorelease pool has a list of such objects and releases them at the top of the runloop.
Now it is clear that some parts of the system are maintaining retain counts and some of this happens behind the users back: i.e. create an object, add it to a container, release it. The retain count is now 1 for the object, as it is pointed at by the container ( i.e NSArray etc.). If the code creates a sub-container, and adds the object to it then the retain count is 2. all of this for an object the programmer has explicitly released. when both containers are released they release their objects, and the objects are dealloced. If only one container is released most of it;s objects are dealloced, except for those in the subarray. This is but one example, but it is not quite all manual on OS X.
So
all objects (NSString etc) created in a local scope are to be added to the autorelease pool and released at the top of the runloop.
All instance variables have a retain count of one when alloced. when the containing object is released they are released ( now done manually by the coder in - (void)dealloc ).
The container stuff stays as is.
That may not be efficient but could work. I dont see this as difficult the copland challenge.
I just see Siracusa trying to hold onto his position and not doing particularly well. He is having to revert to a "My Defined Future" is where the problem is.
It's a discussion of problems that may occur in the future. It necessarily requires speculation about what the future will be like, and why that will lead to problems. What is the alternative to "reverting to 'my defined future'" as you call it? Getting a time machine?
Quote:
And you only argument that isn't contrived is that pointers/direct address manipulation isn't hidden in Obj-C compared to Java or unlocked like C#. While that is true on it's own it is hardly the fault to doom an operating system API and by association the entire operating system platform, ala Copeland.
I never said OS X was "doomed" or that it would suffer the same fate as Copland (an OS that was never released). My blog posts are about how Mac OS X could find itself in the same position that classic Mac OS found itself in during the early 1990s. That situation in turn led to the several failed efforts to fix the situation, one of which was Copland.
Quote:
And it totally ignores the poionts I made unless you are counting your incorrect statement: "Despite the performance hit, increased abstraction always wins in the end because it makes humans more efficient. This has happened time and time again in the PC industry, and it will happen as long as computing power continues to increase."
I am indeed counting it, and I believe it.
Quote:
Increased abstraction has it's place, but enforced pure abstraction of the type you are campaigning for and stating is a requirement is not an acceptable answer for anything which requires time critical computing.
Yours is view based on today's technology, not tomorrow's. Similar things were said about the ability to directly address cylinders, tracks, and sectors on hard disks.
Quote:
I also put in the disclaimer to let others know I am biased against Ars for the stated reasons. Reasons that caused me to vote with my pocketbook. That's considered a common practice in journamism and opinion pieces throughout the mass communications media. So something done in fairness has become interesting?
Oh, okay. As long as you're insulting me in the cause of "fairness." I can see how your noble disclaimer would have been ineffective without calling me an "ignorant blowhard." Also, you might want to choose a word other than "biased," which my dictionary defines as "to show prejudice for or against (someone or something) unfairly."
How about, instead of objects being specifically stated to be retained, they were retained by default, and needed to be specifically *not* retained? Would that make it more palatable to you? It's ref-counted GC by default, but easily escapable for when it needs to be. Your `safety by default', but with a thin veneer that's easily reached through.
Keep in mind that the phrase "saftey by default" covers more than just memory management. It's also about not being able to hose memory, cast object references to ints and increment them, and all that wacky pointer stuff. Anyway, on your memory management suggestion, if you're going to go that far you might as well just go with GCed Obj-C. No sense making a pit-stop in the land of Perl-5-style naive reference counting.
Quote:
Quote:
Sun (with Java) and MS are doing "saftey by default" today and don't seem to be going out of business because of it.
I thought you *weren't* saying it would kill Apple...
I was pointing out that going with "managed code" today does not seem to be a "corporation killer" either
Quote:
I program daily in Python, and while I love the GC during development, it turned out to have a much larger negative impact on runtime than I ever thought it would. Instead, I have the default GC turned off, and I trigger explicit culling runs at well-defined points in the execution. [...]
This is *precisely* the sort of thing I'm talking about when I say that while GC is good, it's not universally good, and the current implementations are even less so. The developer *has* to be able to tell the runtime to stop the GC mucking about, or be able to control how it triggers, when it triggers, and how to handle pathological cases.
Think about disk paging and virtual memory in light of your comments above. Yeah, you can wire down pages today, but few programs outside the kernel have the need to do that. Everyone else just takes their chances.
From the perspective of someone 20 years ago, "mandatory, enforced" virtual memory seems insane. Today, it's just taken for granted that you'll never be sure how much of your app is actually in RAM, and how much is on disk (which is still very slow relative to memory and CPU, even (actually, "especially") today). And yet somehow, useful, interesting, even high-performance applications still manage to be made in this oppressive environment
Quote:
Quote:
Look at it this way: worst case, we still have more abstraction than exists today (Obj-C vs. "managed code") and things go faster.
Not to get bogged down in minutia here, but, are you stating that the managed code is faster than Obj-C? Or that things are faster now than they were in the past? I'm not entirely sure how to parse this sentence.
I was saying that, in the worst case, we could keep the level of abstraction around today's "Java-level" and then just let the hardware get faster. We'd still have more abstraction than Obj-C has today ("Java-level" > "Obj-C level") but the code would eventually run faster than Obj-C runs today. Not that I think this scenario will play out, but I was just saying, worst case, Java-level abstraction still ends up faster than what's considered "acceptable" today.
Quote:
While plenty of real, useful apps *will* be developed and shipped using the current state of the art in GC, many more will suffer greatly if attempted using the same techniques. And then you have time being spent on figuring out how to get *around* the GC, how to encapsulate *that* behaviour, etc. There went some of that hard-won efficiency.
You're still thinking too near-term. How much time is spent figuring out how to get around virtual memory and then encapsulating that behavior? Those kinds of costs are paid once during the transition and then become decreasingly important as time marches on.
Quote:
And given that the biggest rallying cry for GC has been, IMO, "You don't have to ever think about it", I see GC in its current incarnation in technology, and industry perception, as limiting, not enhancing, future abstraction.
Rallying cries tend to be hyperbolic, but everything's relative. "Don't have to think about it" is a close approximation when comparing, say, Java to C.
Quote:
You're thinking 2010, I'm thinking 2020. I'd hate to see a stop-gap measure, in GC, cause yet another round of this, but on a far more important level of abstraction.
So you want to skip right from malloc() and free() calls to the promised land, eh? Obviously there are many steps along the way. I think GC is an important one, and I think we'll spend a long time there. I don't see it as a "stop-gap" at all, especially since there's no obvious "next stage" that we're eschewing for the "quick and dirty fix" of GC.
all objects (NSString etc) created in a local scope are to be added to the autorelease pool and released at the top of the runloop.
All instance variables have a retain count of one when alloced. when the containing object is released they are released ( now done manually by the coder in - (void)dealloc ).
The container stuff stays as is.
That may not be efficient but could work. I dont see this as difficult the copland challenge.
Copland didn't happen because the solution was so technically difficult. Just look at what Jobs and NeXT made during the same span of time that Apple spent going down several dead-ends with nothing to show for it. Had Apple started on a NeXT-style OS design to begin with, it would have been done a lot sooner than Mac OS X was. (And it would have cost a lot less than spending millions on failed projects and then buying NeXT for $400M.)
The problems that led to Copland (and Taligent and Pink and Newton (which started as a successor to the Mac, believe it or not)) were political and strategic much more so than they were technical. Put simply, Apple procrastinated too long and then made some bad choices. Part 3 of my blog series will consider Apple's choices on the memory-managed language/API front: what they could, should, and may do.
Keep in mind that the phrase "saftey by default" covers more than just memory management. It's also about not being able to hose memory, cast object references to ints and increment them, and all that wacky pointer stuff.
NO argument there. While I use that wacky stuff from time to time, I think there are better ways of going about it.
Quote:
Anyway, on your memory management suggestion, if you're going to go that far you might as well just go with GCed Obj-C. No sense making a pit-stop in the land of Perl-5-style naive reference counting.
I'm thinking in practical terms, how to migrate without breaking all the existing code out there. We saw how well that worked with telling developers of Mac Toolbox code to 'just use Cocoa'.
Get the Cocoa guys thinking safety by default, get the level of abstraction into place, and then you can muck with the back end later to get the right effects.
Quote:
I was pointing out that going with "managed code" today does not seem to be a "corporation killer" either
No, it's not, and it won't be... but it may very well end up being a major limitation for the entire industry, if taken as a panacea and a holy grail.
Quote:
Think about disk paging and virtual memory in light of your comments above. Yeah, you can wire down pages today, but few programs outside the kernel have the need to do that. Everyone else just takes their chances.
From the perspective of someone 20 years ago, "mandatory, enforced" virtual memory seems insane. Today, it's just taken for granted that you'll never be sure how much of your app is actually in RAM, and how much is on disk (which is still very slow relative to memory and CPU, even (actually, "especially") today). And yet somehow, useful, interesting, even high-performance applications still manage to be made in this oppressive environment
Ah, but there's a huge difference between the deterministic behaviour of VM, and the semantics of abstractions. Huge. Massive. Gulf-like.
Quote:
I was saying that, in the worst case, we could keep the level of abstraction around today's "Java-level" and then just let the hardware get faster. We'd still have more abstraction than Obj-C has today ("Java-level" > "Obj-C level") but the code would eventually run faster than Obj-C runs today. Not that I think this scenario will play out, but I was just saying, worst case, Java-level abstraction still ends up faster than what's considered "acceptable" today.
No argument there, but I thought that the entire point of this was to *INCREASE* the abstraction level? God knows I think it needs it.
Quote:
You're still thinking too near-term. How much time is spent figuring out how to get around virtual memory and then encapsulating that behavior? Those kinds of costs are paid once during the transition and then become decreasingly important as time marches on.
That works great for encapsulation and management of techniques and systems that are deterministic, or at least have well-formed semantics. We're not there yet with object management. (I'm working on it, I'm working on it...) You'll notice, going back into the literature on VM and such, that *they* didn't become wide-spread until the underlying semantics were defined. That's the tipping point.
Once those semantics for object management are in place, then and only then will we have a shot at really making GC a platform for increased abstractions in the future. Right now, it's not, it's a rug to sweep things under. My fear is that that sort of training of programmers to not think about it will only lead to a dumbing down of the talent. Heck, I already run into people in academia and industry who haven't a clue how to handle basic object management even when they *need* to. Instead, they come up with byzantine systems to work around what they consider to be The One True Way of GC. Bzzzt. I'm already seeing the effects of always-on GC: programmers who really *don't* think.
Quote:
Rallying cries tend to be hyperbolic, but everything's relative. "Don't have to think about it" is a close approximation when comparing, say, Java to C.
Unfortunately, too many people listen to the hyperbole, and that's it. End result: fewer useful abstractions, because the details have been deemed 'not worth thinking about'. When they are.
Quote:
So you want to skip right from malloc() and free() calls to the promised land, eh? Obviously there are many steps along the way.
Yeah, I'm building them.
Quote:
I think GC is an important one, and I think we'll spend a long time there. I don't see it as a "stop-gap" at all, especially since there's no obvious "next stage" that we're eschewing for the "quick and dirty fix" of GC.
Ah, but there's a huge difference between the deterministic behaviour of VM, and the semantics of abstractions. Huge. Massive. Gulf-like.
There's no difference from the perspective of an individual program. Both GC and swapping could happen at any time due to forces outside the program's control.
Quote:
You'll notice, going back into the literature on VM and such, that *they* didn't become wide-spread until the underlying semantics were defined. That's the tipping point.
In the case of VM, the semantics have constantly been redefined in subtle and not-so-subtle ways. Compare the VM implementation of Linux, Mac OS X, classic Mac OS, Window NT 4, and Windows 95. The tipping point is when it ceases to matter for most programs, most of the time. We're way past that with VM, and we'll get to that point with memory management too.
Quote:
My fear is that that sort of training of programmers to not think about it will only lead to a dumbing down of the talent.
Ah yes, Grumpy Old Man Syndrome I posted about that in the comments of part 2 got it too. It sounds crazy to say that a good programmer has to understand analog electronics, but that was the prevailing wisdom of grumpy old men once too. Time marches on. Yes, there is always short-term pain during abrupt transitions (witness all the bloated, slow, poorly designed VB and Java programs out there) but things will work out in the end. In the aggregate, people "dumbed down" in one area get "smartened up" in another.
Quote:
I'll send you my dissertation.
Considering the time lag between the Jef Raskin's "Quick Draw Graphics System" dissertation (1969) and the release of the Mac (1984), you'll forgive me for being a bit impatient...
There's no difference from the perspective of an individual program. Both GC and swapping could happen at any time due to forces outside the program's control.
But swapping is a system that we understand the underlying mechanisms for, that have well defined triggers that are within the boundaries of the machine model, and has a formal basis that is deterministic.
None of the above apply for object management as abstractions.
Quote:
In the case of VM, the semantics have constantly been redefined in subtle and not-so-subtle ways. Compare the VM implementation of Linux, Mac OS X, classic Mac OS, Window NT 4, and Windows 95.
Ah, don't confuse the underlying semantics with the implementations! Two very different arenas. The semantics haven't changed appreciably in 30 years, but the implementations keep getting better.
Quote:
The tipping point is when it ceases to matter for most programs, most of the time. We're way past that with VM, and we'll get to that point with memory management too.
Only once the semantics are nailed down. They're not.
And there you jumped from 'object management' to 'memory management'. Which do you mean? They are two very different areas. The latter is pretty well hammered out, but the former doesn't even have a standard formal notation or terminology, much less a denotational semantics that's worth much. And there lies the problem with GC as it currently stands - it tries to map raw memory management techniques onto object management. Doesn't work. Objects add a distinct layer of developer-directed intent and semantics over the top, and any GC system that ignores those is going to hobble the developer using those semantics. Period.
Right now, those semantics are informally learned, passed on, and used as non-selfconscious constructs, to borrow Alexander's term. Because of that, they're seen as fuzzy concepts that people tend to just lump together. They're not, and until they're worked out as distinct programming concepts, and can be supported in languages (or at least libraries), trying to shove that lump under GC is just doing us all a great disservice.
Quote:
Ah yes, Grumpy Old Man Syndrome I posted about that in the comments of part 2 got it too. It sounds crazy to say that a good programmer has to understand analog electronics, but that was the prevailing wisdom of grumpy old men once too. Time marches on. Yes, there is always short-term pain during abrupt transitions (witness all the bloated, slow, poorly designed VB and Java programs out there) but things will work out in the end. In the aggregate, people "dumbed down" in one area get "smartened up" in another.
*LOL* Waitaminnit - I get labeled Grumpy Old Man because I'm trying to prepare people for a sea change that hasn't happened yet?
Isn't that a little backwards?
We're *this close* to being able to discuss object management issues *independent of memory management*, and have a solid formal mapping between the two for GCs to play with and work *more* efficiently. Running forward with the current GC model is just going to train programmers to ignore those issues, and we'll never get to where we want to be without another massive re-training effort. Bollocks to that.
At this point, all I can assume is that you're just missing the point. Which is fine, your focus is apparently memory management, not object management. Not surprising, since GC confuses the two already.
Quote:
Considering the time lag between the Jef Raskin's "Quick Draw Graphics System" dissertation (1969) and the release of the Mac (1984), you'll forgive me for being a bit impatient...
Let's see... 1984 - 1969 = 15 years, I said I was looking at 2020... yup, about right.
Just try not to shoot the rest of us in the foot while you're advocating a stop-gap measure would you? Thanks.
Edit: you know though... it occurs to me that if you can help push for GC everywhere, such that programmers find themselves in a bind with object management, I can swoop in in a decade and make filthy lucre showing them the way out. Muahahahahaha. Go for it!
And there you jumped from 'object management' to 'memory management'. Which do you mean? They are two very different areas. The latter is pretty well hammered out, but the former doesn't even have a standard formal notation or terminology, much less a denotational semantics that's worth much. And there lies the problem with GC as it currently stands - it tries to map raw memory management techniques onto object management.
It's not as bad as all that. VMs like Parrot at least try to separate object destruction from deallocation, use lazy allocation, etc. I think where we differ is that I don't think "a standard formal notation or terminology" and other rigorous academic definitions are required before something useful and worthwhile can be done in the real world. Worse is Better, remember? Unix has been hanging in there, and has been taught quite a few new tricks while we all wait for Hurd or AST's Microkernel OS of the Future or what have you. That's not to say that those things won't come to pass eventually, but in the meantime I'm glad we have what we do.
Quote:
Let's see... 1984 - 1969 = 15 years, I said I was looking at 2020... yup, about right. Just try not to shoot the rest of us in the foot while you're advocating a stop-gap measure would you? Thanks.
Like I said, forgive me if I'm not willing to stick with malloc() and free() (or even retain/release/autorelease) while I wait until 2020
The free market also doesn't take too kindly to long waits. Getting back to the Copland 2010 thing, what's Apple to say in 2010 when CLR/C#/Java programmers are experiencing real, measurable productivity gains thanks to their languages and environments? "Oh, that stuff's a stop-gap. We'll have the real solution in 2020, just wait!" Shareholders and developers alike won't be too keen on that. The world is a tough old place.
Originally posted by John ]It's not as bad as all that. VMs like Parrot at least try to separate object destruction from deallocation, use lazy allocation, etc. I think where we differ is that I don't think "a standard formal notation or terminology" and other rigorous academic definitions are required before something useful and worthwhile can be done in the real world. Worse is Better, remember? Unix has been hanging in there, and has been taught quite a few new tricks while we all wait for Hurd or AST's Microkernel OS of the Future or what have you. That's not to say that those things won't come to pass eventually, but in the meantime I'm glad we have what we do.
Certainly. Like I said, *I* use a GC'd language daily, and am glad to. I just know when to step in and take over for it though, *because I understand the issues*. Programmers who never get taught the issues because 'it's managed' may be gaining some (where 'some' varies from environment to environment) efficiency for 90% of the code - but then they're frickin' *stuck* when they hit that last 10%. This is when you see all sorts of bizarre schemes get proposed, when all they have to do is turn the GC off for that 10% and do a little handling on their own. (And *why* do they have to turn the GC off? Because it's not smart enough to know how the objects should be treated.)
But that expertise in handling isn't taught or passed down because, well, 'it's managed'. Urk.
Look, we agree that GC is good. We agree that it can lead to some big gains for simple code. Where I think we disagree is where GC needs to go next - in my experience, it breaks down for too many situations that could be easily handled if it would step out of the way, because GC in general is simply not smart enough about developer intent, and the developer has no way of telling the GC what they want, other than 'handle this, don't handle that'. You've got to admit that's pretty damned primitive.
Where are the selections for 'handle that completely', 'treat this as a unique instance, never to be shared, but can be passed around', 'this object is a shared resource, period', and so on? These are higher level abstractions that are necessary for properly discussing even higher level abstractions such as design patterns. Heck, C++ is getting there with the proposed shared_ptr, unique_ptr and so on. It'd be ironic if *C++* leapfrogs C# for object management possibilities, don't you think?
And yet, that conceptually-based approach to object management, making the developer aware of precisely where and how they expecting objects to act, and being able to tell the runtime exactly their intent... that's the future. Not "Are you done with this? I think he's done with this. ANYONE USING THIS? Okay, I'll throw it away... wait... I thought you said you were done with it! Well you didn't *SAY* anything..." which is kind of what memory management is like. GC treats objects as, well, blocks of memory, independent of how they were intended to be used.
With a clear communication path of intent, it becomes really freaking easy to have safety by default, because the runtime and the developer are in sync over precisely how objects are to be used.
Quote:
Like I said, forgive me if I'm not willing to stick with malloc() and free() (or even retain/release/autorelease) while I wait until 2020
Gripe, gripe, gripe.
I think there are a number of schemes that could be used - I'll be interested to see what you come up with in article 3.
Quote:
The free market also doesn't take too kindly to long waits. Getting back to the Copland 2010 thing, what's Apple to say in 2010 when CLR/C#/Java programmers are experiencing real, measurable productivity gains thanks to their languages and environments? "Oh, that stuff's a stop-gap. We'll have the real solution in 2020, just wait!" Shareholders and developers alike won't be too keen on that. The world is a tough old place.
Yup, it is. And free markets have a problem when it comes to looking to the future, no doubt about it. Which is why I'm going to keep advocating *object* management systems that are a wee bit more intelligent than the crop of *memory* management systems we have now. We're almost there, and pushing memory-based management schemes for objects, ala current GC systems, isn't playing catch-up, it's following others down a dead end. At some point, the switchover has to occur, for object-based languages to continue to advance in levels of abstraction. I say lead the way, don't waste resources heading down a path that we already know stops short of where it should.
I mean, you started this with talking about Copland - the poster child for trying to tack things on to an old model if ever there was one. Don't you see that current GCs are the model on which ever more layers of cruft are getting tacked? They're going to collapse under their own weight at some point, and I don't think that day is too far off, when the semantics of the GC, not the performance, become what holds the languages and the developers back.
I think Obj-C and Cocoa are in a decent position right now for adding a serious object management system, and leapfrogging the memory management approaches used in current GCs. That would leave CLR/C# playing catch-up not in 2020, but in 2010. Much nicer, no?
And, I think it could be done without breaking the current code. Hmmm. Blast you, now you have me thinking about something other than my defense. *shakes fists*
In the case of VM, the semantics have constantly been redefined in subtle and not-so-subtle ways. Compare the VM implementation of Linux, Mac OS X, classic Mac OS, Window NT 4, and Windows 95. The tipping point is when it ceases to matter for most programs, most of the time. We're way past that with VM, and we'll get to that point with memory management too.
The real tipping point for VM was after the semantics were solid enough to allow for design of appropriate dedicated hardware to generate the needed speed. Before that VM was a nice topic for dissertations, but too slow to be universally considered for mandatory use. After VM hardware was designed and operating properly, the programmer's need to manually maintain overlays went away. Not only was maintaining overlays hard, but it was too slow compared to the new solution. Note this is very different from you prediction that future simple speed increases in hardware will automagically make us unconcerned with the performance hit. The memory managed API process is still in software, and still sapping performance.
Another huge reason for system wide VM to which enforced memory managed API's have no equivalent is multiprogramming. VM allows many programs to play nice simultaneously having the OS play traffic cop. Memory management schemes in the context of your article have effects limited to the interior to a single program. There is no analogous common exterior driving force to VMs solution as a way to efficiently share the machines physical resources. Not to mention that within the year, 4 of the 5 OSes you cited with diferent VM implementations will al be using their individual implementations on top of the identical paging hardware support on the same CPU [Only Classic is left out in the cold]. The semantics aren't nearly as different as you would lead others to believe.
I don't see dedicated hardware figuring into garbage collection/managed memory ops in the near-to-mid term to save the speed hit that currently drives non-deterministic garbege collected program execution timelines.
Look, we agree that GC is good. We agree that it can lead to some big gains for simple code. Where I think we disagree is where GC needs to go next - in my experience, it breaks down for too many situations that could be easily handled if it would step out of the way, because GC in general is simply not smart enough about developer intent, and the developer has no way of telling the GC what they want, other than 'handle this, don't handle that'. You've got to admit that's pretty damned primitive.
See, I think that's a problem with the feature set of the language, not of the GC implemented to support it.
Quote:
Where are the selections for 'handle that completely', 'treat this as a unique instance, never to be shared, but can be passed around', 'this object is a shared resource, period', and so on?
Actually, maybe we disagree on terminology. Why isn't a language implementation that includes the feature as you describe above still "garbage collected"? Because the language supports hints that a garbage collector could use in its implementation? I don't limit GC to just "dumb memory tracking for dumb languages." Garbage collectors get smarter all the time, and languages are getting smarter with them. It's parallel evolution.
Some strategies and some combinations are going to be losers, but the ones that work will continue the line, so to speak. The sometimes-loose coupling (probably too loose for your tastes) between language features and the GC implementation will actually help in the early years of this transition because loser GCs can be swapped out for better ones. Just look at the evolution of Java VMs. They've come a long way in a short time, with the best of the best give C/C++ a run for the money in some tasks.
Quote:
"Are you done with this? I think he's done with this. ANYONE USING THIS? Okay, I'll throw it away... wait... I thought you said you were done with it! Well you didn't *SAY* anything..."
I'll just add that there's a built-in assumption that this kind of mistake on the part of the memory management system is important. Long term, it won't be. And in the interim, there are already ways to signal things like "hey, keep this around because I'm going to need it shortly" and "throw this away, I'm done with it now." They may be primitive (keep a reference, weaken a reference, control scope) but they do exist and are actually used today.
Quote:
I think there are a number of schemes that could be used - I'll be interested to see what you come up with in article 3.
I doubt you will, since I'll be talking a lot about existing high-level languages and APIs, and pretty much not at all about stuff that doesn't exist yet, but would be even better if it did
Quote:
I'm going to keep advocating *object* management systems that are a wee bit more intelligent than the crop of *memory* management systems we have now.
See, I don't think this distinction is very meaningful at anything below the language level, and plenty of high-level languages already think of resource management in terms of objects.
Quote:
I mean, you started this with talking about Copland - the poster child for trying to tack things on to an old model if ever there was one. Don't you see that current GCs are the model on which ever more layers of cruft are getting tacked?
No, I see them as a replaceable engine upon which increasingly abstracted languages can run (and run increasingly better, if all goes well).
Quote:
I think Obj-C and Cocoa are in a decent position right now for adding a serious object management system, and leapfrogging the memory management approaches used in current GCs. That would leave CLR/C# playing catch-up not in 2020, but in 2010. Much nicer, no? And, I think it could be done without breaking the current code.
If you have a plan for this, I'm sure Apple would like to hear it. But I wonder what you're going to do about the pointer situation, C/C++ compatibility, and all that jazz.
The real tipping point for VM was after the semantics were solid enough to allow for design of appropriate dedicated hardware to generate the needed speed [...] Note this is very different from you prediction that future simple speed increases in hardware will automagically make us unconcerned with the performance hit.
I never said anything about the simplicity of the performance increases that will eventually render GC performance a non-issue. I doubt it will be dedicated hardware, but I don't rule it out either. It could just as easily simply be a huge surplus of fast memory. But my bet is that the advantages of managed memory will outweigh the performance pitfalls long before all the performance issues disappear entirely. In some areas, some would say that's already happened. Certainly MS and Sun seem to think so.
See, I think that's a problem with the feature set of the language, not of the GC implemented to support it.
The two go hand in hand, as I stated - we need better object management, *AND* better ways to tell the underlying technology (GC, for lack of a better term) what we want. That's where the language comes in.
Like I said, I don't think we're that far off on this.
Quote:
Actually, maybe we disagree on terminology. Why isn't a language implementation that includes the feature as you describe above still "garbage collected"? Because the language supports hints that a garbage collector could use in its implementation? I don't limit GC to just "dumb memory tracking for dumb languages." Garbage collectors get smarter all the time, and languages are getting smarter with them. It's parallel evolution.
Yup, it is. *Current* GCs mangle memory management with object management badly. I don't see that changing until the language support is there to communicate intent, and until there's a solid definition for at least some of the object semantics. Whether you call it GC, OC, or Fortran, it's still the same basic principle - taking care of things the developer is done with.
Quote:
Some strategies and some combinations are going to be losers, but the ones that work will continue the line, so to speak. The sometimes-loose coupling (probably too loose for your tastes) between language features and the GC implementation will actually help in the early years of this transition because loser GCs can be swapped out for better ones. Just look at the evolution of Java VMs. They've come a long way in a short time, with the best of the best give C/C++ a run for the money in some tasks.
Actually, a good semantics allows for the implementation to be swapped out more easily, because the requirements for the interface are better understood. Like I said, I think the next big leap is going to be GCs that are object *intent* aware, not just object aware.
Quote:
I'll just add that there's a built-in assumption that this kind of mistake on the part of the memory management system is important. Long term, it won't be. And in the interim, there are already ways to signal things like "hey, keep this around because I'm going to need it shortly" and "throw this away, I'm done with it now." They may be primitive (keep a reference, weaken a reference, control scope) but they do exist and are actually used today.
EXACTLY! *BING BING BING* WHOOHOO!
That's been pretty much my point all along, that *THAT* is where the push for GCs needs to be - communicating intent to the GC subsystem, by making the bloody thing more intelligent about object management.
Saying that "Well, it's primitive, so let's get rid of it" isn't the approach to take. I don't think that's what you're advocating, but god knows I've run into more than one yahoo who thought that way. It's primitive, sure, but it's the place to be focussing the effort.
Unfortunately, the current state of the art in GC seems to be going in the other direction.
Quote:
I doubt you will, since I'll be talking a lot about existing high-level languages and APIs, and pretty much not at all about stuff that doesn't exist yet, but would be even better if it did
Naw, it'll be fun to see how close you get.
Quote:
See, I don't think this distinction is very meaningful at anything below the language level, and plenty of high-level languages already think of resource management in terms of objects.
For some things, no, it's not important - but as you increase abstraction, you need to increase language support for same. Object management is one heck of an abstraction that hasn't really been addressed past the syntactic level in most languages, and that's at best.
Quote:
No, I see them as a replaceable engine upon which increasingly abstracted languages can run (and run increasingly better, if all goes well).
You can pull out the guts of the engine, but until the engine starts treating object management as something more than raw chunks of memory that are either active or not, the situation isn't going to change appreciably. All you're doing there is making a semi-intelligent engine even faster at being semi-intelligent.
Unfortunately, as we've both been saying, without support at the language level, the code can't provide the engine with the information it needs. So right now we're in a chicken and egg situation - no one is going to adopt a brand spanking new language with new keywords that can't be really well implemented on the backend, and no one is going to put the effort into working on that backend without a practical language with developers.
Quote:
If you have a plan for this, I'm sure Apple would like to hear it. But I wonder what you're going to do about the pointer situation, C/C++ compatibility, and all that jazz.
I thought we were talking about objects?
Seriously, one of the nice things about Obj-C is that it's utterly schizo - the object model and the procedural model are damned near partitioned. Some people hate it, I love it, because it allows each model to be quite 'pure', but interconnected. It's like being able to jump between Smalltalk and C at will to use each for the things it does best. The only place where schemes for solid object management are going to be possible are on the object side, obviously. If you look at most Obj-C code, it's quite well separated into object and procedural parts. GC for procedural systems is actually closer to the theoretical limits of the language abstractions than on the object side. I say let the two sides handle their own issues in the ways they know best. The amount of overlap is generally very small, and the underlying bridge (aha!) in the runtime is the appropriate place to handle boundary issues.
I never said anything about the simplicity of the performance increases that will eventually render GC performance a non-issue. I doubt it will be dedicated hardware, but I don't rule it out either. It could just as easily simply be a huge surplus of fast memory. But my bet is that the advantages of managed memory will outweigh the performance pitfalls long before all the performance issues disappear entirely. In some areas, some would say that's already happened. Certainly MS and Sun seem to think so.
I know you didn't directly say anything about simplicity, but your point that speed increases alone will compensate adequately for the performance issues IS a simple solution to the problem. I just don't agree that is enough, by a long shot, for enforced full time memory managment/GC. And further distance that possibility by showing your VM example was not cleanly analogous because it required a non-trivial infusion of dedicated hardware to become ubiquitous today, something a simple speed-up of CPUs will not offer MM/GC.
I personally agree with the lions share of what Kickaha is saying, he can put it a lot more eloquently and precicely that I can, being in his personal scope of interest. In my short version it is "Choice is good", and I see the addition of sane GC to Obj-C a likely good middle ground solution, not half-baked and dooming OS X to Copland-like obscurity in the future. Sure, the execution could end up screwed, but then that isn't the idea's fault but the implementation's, and we won't know that until it is unveiled.
I would sit back and watch, go ahead and mention some potential pitfalls, but not universally condemn up front using highly loaded examples like a failed Copeland project. That's just trolling for hits and goes back to my current bias against Ars generated from several years of hanging around that community and seeing the changes I'm not happy with. And by my dictionary, bias is only "usually unfair". So biased I am, and personally and ego diven as it may be, see my bias as fitting in the exception delinated by that little word usually. If you or anyone else think it's unfair, it doesn't break my heart. But do notice, even though we have been in strong disagreement, this isn't a barely-shrouded-profanity laden flamefest.
Comments
Sooooo... what you're saying is that you want fully-auto GC for when it makes sense, and the option of dropping out of it when it doesn't.
Which is *PRECISELY* my position. Your articles seem to press for auto-GC 24/7, because hey, the hardware will catch up.
Eventually, "saftey by default" (as I call it in the article) will be the minimum standard. In part 2 I talk about dropping down to lower-levels, specifically how it's too easy in Obj-C. (Arguably, you're always at a lower-level in Obj-C since even "objects" involve thinly disguised and generally unprotected pointers. It's a long way from "managed code" in the Java/CLR style.)
Sure, the history of programming abstractions is a punctuated equilibrium model, and is very likely that hardware will provide speed boosts greater than the plateaus in the model, but if you look at the spikes, hardware, historically, can't keep up. It catches up, and then the next evolution occurs, and blammo.
Sun (with Java) and MS are doing "saftey by default" today and don't seem to be going out of business because of it. (Okay, we'll see about Sun ;-) Look at it this way: worst case, we still have more abstraction than exists today (Obj-C vs. "managed code") and things go faster. Yes, there will always be the next big thing to suck resources, but the "dotted line" I mention in my article between stuff that's "nice, but too slow" and stuff that's ready to be used in real applications inevitably rises.
Maybe, when that day comes, a default of auto-GC will be the best approach
I'm sure you'll find a lot of Java, C#, Python, Ruby, Lisp, etc. programmers who will argue that that day has already come
but until that day comes, and until the precise semantics of the various object management schemes can be captured and enforced systematically, I will continue to have the opinion that auto-GC is an important tool, but one that cannot be pushed as a universal solution.
I think your viewpoint is a bit too constrained. Plenty of real, useful apps can be developed and shipped without ever really "solving" (in the rigorous sense) any of the stuff you're researching. The industry is already getting by with "good enough" in many cases, and I expect it will continue to do so.
Originally posted by mrmister
I love it when Mr. Siracusa shows up, and suddenly a lot of tails are tucked between people's legs.
It pays to keep your rhetoric under control--because you get called on it, when you least expect it.
I just see Siracusa trying to hold onto his position and not doing particularly well. He is having to revert to a "My Defined Future" is where the problem is. The only problem is it's obvious fron the comments on his articles and here that those with brains switched on don't buy his future as being the most likely one. Hence his negative points, while seemingly supporteby accurate lower level technical details, become quite excessively brittle when faced with higher level "Non-Siracusa Defined Future" reality.
Originally posted by John
You seem to be assuming that I don't know that C# and Java use forms of garbage collection. I'm not sure where you got that idea. When I called Obj-C with GC a "half-solution," I meant that it is an attempt to have your cake and eat it too, so to speak, much like Copland was.
IOW, it's an attempt to add a feature to an existing technology where it may not fit in well and where it doesn't really solve the problem completely (e.g., Copland's plan to add MP/PMT to Mac OS while still allowing some processes to run "unprotected") instead of cutting the Gordian knot by pushing the old ways off to the side in favor of a (relatively) clean slate (e.g., Mac OS X's design with its BSD base, Cocoa, and the classic environment for backward compatibility, which allowed Carbon to abandon the worst of the cruft and break compatibility where necessary)
In part 2 you can read more about why I think Obj-C with GC is not an adequate solution in the long run.
I also talk more about performance issues in part 2.
Well, I don't see any meaningful mention of performance issues. And you only argument that isn't contrived is that pointers/direct address manipulation isn't hidden in Obj-C compared to Java or unlocked like C#. While that is true on it's own it is hardly the fault to doom an operating system API and by association the entire operating system platform, ala Copeland. And it totally ignores the poionts I made unless you are counting your incorrect statement: "Despite the performance hit, increased abstraction always wins in the end because it makes humans more efficient. This has happened time and time again in the PC industry, and it will happen as long as computing power continues to increase." That is hardly a universal truth.
Increased abstraction has it's place, but enforced pure abstraction of the type you are campaigning for and stating is a requirement is not an acceptable answer for anything which requires time critical computing. The perfect general solution exists nowhere, not even in the languages you cite. Damning another is hardly going to fix anything, and doesn't make the other languages any better.
That's an interesting statement from someone who began his post with "Siracusa is an ignorant blowhard"
Not really, although I do see the touch of irony. The typical Arsian flame war begins with strategic culling of context. Something you are guilty of here. The next sentence read: "It got too popular and is now becoming too polarized by more and more opinionated reporting and the Battlefront is everywhere, not just the Battlefront."
I also put in the disclaimer to let others know I am biased against Ars for the stated reasons. Reasons that caused me to vote with my pocketbook. That's considered a common practice in journamism and opinion pieces throughout the mass communications media. So something done in fairness has become interesting? That's a sad stament on society and the state of bloggers in general.
Originally posted by John
Eventually, "saftey by default" (as I call it in the article) will be the minimum standard. In part 2 I talk about dropping down to lower-levels, specifically how it's too easy in Obj-C. (Arguably, you're always at a lower-level in Obj-C since even "objects" involve thinly disguised and generally unprotected pointers. It's a long way from "managed code" in the Java/CLR style.)
Yes, it is, and as I've been saying all along, I think Obj-C needs something better for object management. The current model is quite good, but the enforcement stinks. It's too easy to break.
Here's a fliparoonie for you: How about, instead of objects being specifically stated to be retained, they were retained by default, and needed to be specifically *not* retained? Would that make it more palatable to you? It's ref-counted GC by default, but easily escapable for when it needs to be. Your `safety by default', but with a thin veneer that's easily reached through.
Managed code is fine, when you can trust the manager to always be right, or sidestep them as necessary.
Sun (with Java) and MS are doing "saftey by default" today and don't seem to be going out of business because of it.
I thought you *weren't* saying it would kill Apple...
And you're right, their products are being used by many - and shunned by many others due to the GC impact.
I program daily in Python, and while I love the GC during development, it turned out to have a much larger negative impact on runtime than I ever thought it would. Instead, I have the default GC turned off, and I trigger explicit culling runs at well-defined points in the execution. This is an excellent method for having control over the GC... something that I find lacking in Java, and something that I find incomprehensible to most programmers who are strong advocates of GC. "Why would you want to do that? The hardware will eventually catch up..."
This is *precisely* the sort of thing I'm talking about when I say that while GC is good, it's not universally good, and the current implementations are even less so. The developer *has* to be able to tell the runtime to stop the GC mucking about, or be able to control how it triggers, when it triggers, and how to handle pathological cases. Like I said, it's a tool, but the best tools are ones that aren't superglued to your hand.
(Okay, we'll see about Sun ;-) Look at it this way: worst case, we still have more abstraction than exists today (Obj-C vs. "managed code") and things go faster.
Not to get bogged down in minutia here, but, are you stating that the managed code is faster than Obj-C? Or that things are faster now than they were in the past? I'm not entirely sure how to parse this sentence.
Yes, there will always be the next big thing to suck resources, but the "dotted line" I mention in my article between stuff that's "nice, but too slow" and stuff that's ready to be used in real applications inevitably rises.
Sure it does, but you have to be careful not to weight that line down with too much baggage, or it won't rise fast *enough*.
I'm sure you'll find a lot of Java, C#, Python, Ruby, Lisp, etc. programmers who will argue that that day has already come
*waves hand in air*
Yes, but then I matured as a Python programmer, and realized that it wasn't a universal panacea, and I am *SO* thankful that I can manually control the GC system... if I couldn't, Python wouldn't be a viable language for my development process.
I think your viewpoint is a bit too constrained. Plenty of real, useful apps can be developed and shipped without ever really "solving" (in the rigorous sense) any of the stuff you're researching. The industry is already getting by with "good enough" in many cases, and I expect it will continue to do so.
And I think your viewpoint is a bit too hopeful. While plenty of real, useful apps *will* be developed and shipped using the current state of the art in GC, many more will suffer greatly if attempted using the same techniques. And then you have time being spent on figuring out how to get *around* the GC, how to encapsulate *that* behaviour, etc. There went some of that hard-won efficiency.
John, I don't think we're that far apart on this. I'm certainly not in the camp advocating that the current situation is just peachy keen. I'm coming at this from the *other* end, of someone who would dearly love to see much more abstraction than any language right now could even dream of handling... but sees that the core issues for developing solid support for those abstractions is predicated on getting object management conceptualized in all its facets, not swept under the rug. And given that the biggest rallying cry for GC has been, IMO, "You don't have to ever think about it", I see GC in its current incarnation in technology, and industry perception, as limiting, not enhancing, future abstraction. You're thinking 2010, I'm thinking 2020. I'd hate to see a stop-gap measure, in GC, cause yet another round of this, but on a far more important level of abstraction.
Because stop-gaps were what led to Copland in the first place, by your own assertion.
Here's a fliparoonie for you: How about, instead of objects being specifically stated to be retained, they were retained by default, and needed to be specifically *not* retained? Would that make it more palatable to you? It's ref-counted GC by default, but easily escapable for when it needs to be. Your `safety by default', but with a thin veneer that's easily reached through.
Yes. this could be done by making retain/autorelease a no-op. An object that is copied or alloced in Obj C has a retain count of one anyway. Objects that are autoreleased are zero retained, the the autorelease pool has a list of such objects and releases them at the top of the runloop.
Now it is clear that some parts of the system are maintaining retain counts and some of this happens behind the users back: i.e. create an object, add it to a container, release it. The retain count is now 1 for the object, as it is pointed at by the container ( i.e NSArray etc.). If the code creates a sub-container, and adds the object to it then the retain count is 2. all of this for an object the programmer has explicitly released. when both containers are released they release their objects, and the objects are dealloced. If only one container is released most of it;s objects are dealloced, except for those in the subarray. This is but one example, but it is not quite all manual on OS X.
So
all objects (NSString etc) created in a local scope are to be added to the autorelease pool and released at the top of the runloop.
All instance variables have a retain count of one when alloced. when the containing object is released they are released ( now done manually by the coder in - (void)dealloc ).
The container stuff stays as is.
That may not be efficient but could work. I dont see this as difficult the copland challenge.
I just see Siracusa trying to hold onto his position and not doing particularly well. He is having to revert to a "My Defined Future" is where the problem is.
It's a discussion of problems that may occur in the future. It necessarily requires speculation about what the future will be like, and why that will lead to problems. What is the alternative to "reverting to 'my defined future'" as you call it? Getting a time machine?
And you only argument that isn't contrived is that pointers/direct address manipulation isn't hidden in Obj-C compared to Java or unlocked like C#. While that is true on it's own it is hardly the fault to doom an operating system API and by association the entire operating system platform, ala Copeland.
I never said OS X was "doomed" or that it would suffer the same fate as Copland (an OS that was never released). My blog posts are about how Mac OS X could find itself in the same position that classic Mac OS found itself in during the early 1990s. That situation in turn led to the several failed efforts to fix the situation, one of which was Copland.
And it totally ignores the poionts I made unless you are counting your incorrect statement: "Despite the performance hit, increased abstraction always wins in the end because it makes humans more efficient. This has happened time and time again in the PC industry, and it will happen as long as computing power continues to increase."
I am indeed counting it, and I believe it.
Increased abstraction has it's place, but enforced pure abstraction of the type you are campaigning for and stating is a requirement is not an acceptable answer for anything which requires time critical computing.
Yours is view based on today's technology, not tomorrow's. Similar things were said about the ability to directly address cylinders, tracks, and sectors on hard disks.
I also put in the disclaimer to let others know I am biased against Ars for the stated reasons. Reasons that caused me to vote with my pocketbook. That's considered a common practice in journamism and opinion pieces throughout the mass communications media. So something done in fairness has become interesting?
Oh, okay. As long as you're insulting me in the cause of "fairness." I can see how your noble disclaimer would have been ineffective without calling me an "ignorant blowhard." Also, you might want to choose a word other than "biased," which my dictionary defines as "to show prejudice for or against (someone or something) unfairly."
How about, instead of objects being specifically stated to be retained, they were retained by default, and needed to be specifically *not* retained? Would that make it more palatable to you? It's ref-counted GC by default, but easily escapable for when it needs to be. Your `safety by default', but with a thin veneer that's easily reached through.
Keep in mind that the phrase "saftey by default" covers more than just memory management. It's also about not being able to hose memory, cast object references to ints and increment them, and all that wacky pointer stuff. Anyway, on your memory management suggestion, if you're going to go that far you might as well just go with GCed Obj-C. No sense making a pit-stop in the land of Perl-5-style naive reference counting.
Sun (with Java) and MS are doing "saftey by default" today and don't seem to be going out of business because of it.
I thought you *weren't* saying it would kill Apple...
I was pointing out that going with "managed code" today does not seem to be a "corporation killer" either
I program daily in Python, and while I love the GC during development, it turned out to have a much larger negative impact on runtime than I ever thought it would. Instead, I have the default GC turned off, and I trigger explicit culling runs at well-defined points in the execution. [...]
This is *precisely* the sort of thing I'm talking about when I say that while GC is good, it's not universally good, and the current implementations are even less so. The developer *has* to be able to tell the runtime to stop the GC mucking about, or be able to control how it triggers, when it triggers, and how to handle pathological cases.
Think about disk paging and virtual memory in light of your comments above. Yeah, you can wire down pages today, but few programs outside the kernel have the need to do that. Everyone else just takes their chances.
From the perspective of someone 20 years ago, "mandatory, enforced" virtual memory seems insane. Today, it's just taken for granted that you'll never be sure how much of your app is actually in RAM, and how much is on disk (which is still very slow relative to memory and CPU, even (actually, "especially") today). And yet somehow, useful, interesting, even high-performance applications still manage to be made in this oppressive environment
Look at it this way: worst case, we still have more abstraction than exists today (Obj-C vs. "managed code") and things go faster.
Not to get bogged down in minutia here, but, are you stating that the managed code is faster than Obj-C? Or that things are faster now than they were in the past? I'm not entirely sure how to parse this sentence.
I was saying that, in the worst case, we could keep the level of abstraction around today's "Java-level" and then just let the hardware get faster. We'd still have more abstraction than Obj-C has today ("Java-level" > "Obj-C level") but the code would eventually run faster than Obj-C runs today. Not that I think this scenario will play out, but I was just saying, worst case, Java-level abstraction still ends up faster than what's considered "acceptable" today.
While plenty of real, useful apps *will* be developed and shipped using the current state of the art in GC, many more will suffer greatly if attempted using the same techniques. And then you have time being spent on figuring out how to get *around* the GC, how to encapsulate *that* behaviour, etc. There went some of that hard-won efficiency.
You're still thinking too near-term. How much time is spent figuring out how to get around virtual memory and then encapsulating that behavior? Those kinds of costs are paid once during the transition and then become decreasingly important as time marches on.
And given that the biggest rallying cry for GC has been, IMO, "You don't have to ever think about it", I see GC in its current incarnation in technology, and industry perception, as limiting, not enhancing, future abstraction.
Rallying cries tend to be hyperbolic, but everything's relative. "Don't have to think about it" is a close approximation when comparing, say, Java to C.
You're thinking 2010, I'm thinking 2020. I'd hate to see a stop-gap measure, in GC, cause yet another round of this, but on a far more important level of abstraction.
So you want to skip right from malloc() and free() calls to the promised land, eh?
all objects (NSString etc) created in a local scope are to be added to the autorelease pool and released at the top of the runloop.
All instance variables have a retain count of one when alloced. when the containing object is released they are released ( now done manually by the coder in - (void)dealloc ).
The container stuff stays as is.
That may not be efficient but could work. I dont see this as difficult the copland challenge.
Copland didn't happen because the solution was so technically difficult. Just look at what Jobs and NeXT made during the same span of time that Apple spent going down several dead-ends with nothing to show for it. Had Apple started on a NeXT-style OS design to begin with, it would have been done a lot sooner than Mac OS X was. (And it would have cost a lot less than spending millions on failed projects and then buying NeXT for $400M.)
The problems that led to Copland (and Taligent and Pink and Newton (which started as a successor to the Mac, believe it or not)) were political and strategic much more so than they were technical. Put simply, Apple procrastinated too long and then made some bad choices. Part 3 of my blog series will consider Apple's choices on the memory-managed language/API front: what they could, should, and may do.
Originally posted by John
Keep in mind that the phrase "saftey by default" covers more than just memory management. It's also about not being able to hose memory, cast object references to ints and increment them, and all that wacky pointer stuff.
NO argument there. While I use that wacky stuff from time to time, I think there are better ways of going about it.
Anyway, on your memory management suggestion, if you're going to go that far you might as well just go with GCed Obj-C. No sense making a pit-stop in the land of Perl-5-style naive reference counting.
I'm thinking in practical terms, how to migrate without breaking all the existing code out there. We saw how well that worked with telling developers of Mac Toolbox code to 'just use Cocoa'.
Get the Cocoa guys thinking safety by default, get the level of abstraction into place, and then you can muck with the back end later to get the right effects.
I was pointing out that going with "managed code" today does not seem to be a "corporation killer" either
No, it's not, and it won't be... but it may very well end up being a major limitation for the entire industry, if taken as a panacea and a holy grail.
Think about disk paging and virtual memory in light of your comments above. Yeah, you can wire down pages today, but few programs outside the kernel have the need to do that. Everyone else just takes their chances.
From the perspective of someone 20 years ago, "mandatory, enforced" virtual memory seems insane. Today, it's just taken for granted that you'll never be sure how much of your app is actually in RAM, and how much is on disk (which is still very slow relative to memory and CPU, even (actually, "especially") today). And yet somehow, useful, interesting, even high-performance applications still manage to be made in this oppressive environment
Ah, but there's a huge difference between the deterministic behaviour of VM, and the semantics of abstractions. Huge. Massive. Gulf-like.
I was saying that, in the worst case, we could keep the level of abstraction around today's "Java-level" and then just let the hardware get faster. We'd still have more abstraction than Obj-C has today ("Java-level" > "Obj-C level") but the code would eventually run faster than Obj-C runs today. Not that I think this scenario will play out, but I was just saying, worst case, Java-level abstraction still ends up faster than what's considered "acceptable" today.
No argument there, but I thought that the entire point of this was to *INCREASE* the abstraction level? God knows I think it needs it.
You're still thinking too near-term. How much time is spent figuring out how to get around virtual memory and then encapsulating that behavior? Those kinds of costs are paid once during the transition and then become decreasingly important as time marches on.
That works great for encapsulation and management of techniques and systems that are deterministic, or at least have well-formed semantics. We're not there yet with object management. (I'm working on it, I'm working on it...) You'll notice, going back into the literature on VM and such, that *they* didn't become wide-spread until the underlying semantics were defined. That's the tipping point.
Once those semantics for object management are in place, then and only then will we have a shot at really making GC a platform for increased abstractions in the future. Right now, it's not, it's a rug to sweep things under. My fear is that that sort of training of programmers to not think about it will only lead to a dumbing down of the talent. Heck, I already run into people in academia and industry who haven't a clue how to handle basic object management even when they *need* to. Instead, they come up with byzantine systems to work around what they consider to be The One True Way of GC. Bzzzt. I'm already seeing the effects of always-on GC: programmers who really *don't* think.
Rallying cries tend to be hyperbolic, but everything's relative. "Don't have to think about it" is a close approximation when comparing, say, Java to C.
Unfortunately, too many people listen to the hyperbole, and that's it. End result: fewer useful abstractions, because the details have been deemed 'not worth thinking about'. When they are.
So you want to skip right from malloc() and free() calls to the promised land, eh?
Yeah, I'm building them.
I think GC is an important one, and I think we'll spend a long time there. I don't see it as a "stop-gap" at all, especially since there's no obvious "next stage" that we're eschewing for the "quick and dirty fix" of GC.
I'll send you my dissertation.
Ah, but there's a huge difference between the deterministic behaviour of VM, and the semantics of abstractions. Huge. Massive. Gulf-like.
There's no difference from the perspective of an individual program. Both GC and swapping could happen at any time due to forces outside the program's control.
You'll notice, going back into the literature on VM and such, that *they* didn't become wide-spread until the underlying semantics were defined. That's the tipping point.
In the case of VM, the semantics have constantly been redefined in subtle and not-so-subtle ways. Compare the VM implementation of Linux, Mac OS X, classic Mac OS, Window NT 4, and Windows 95. The tipping point is when it ceases to matter for most programs, most of the time. We're way past that with VM, and we'll get to that point with memory management too.
My fear is that that sort of training of programmers to not think about it will only lead to a dumbing down of the talent.
Ah yes, Grumpy Old Man Syndrome
I'll send you my dissertation.
Considering the time lag between the Jef Raskin's "Quick Draw Graphics System" dissertation (1969) and the release of the Mac (1984), you'll forgive me for being a bit impatient...
Originally posted by John
There's no difference from the perspective of an individual program. Both GC and swapping could happen at any time due to forces outside the program's control.
But swapping is a system that we understand the underlying mechanisms for, that have well defined triggers that are within the boundaries of the machine model, and has a formal basis that is deterministic.
None of the above apply for object management as abstractions.
In the case of VM, the semantics have constantly been redefined in subtle and not-so-subtle ways. Compare the VM implementation of Linux, Mac OS X, classic Mac OS, Window NT 4, and Windows 95.
Ah, don't confuse the underlying semantics with the implementations! Two very different arenas. The semantics haven't changed appreciably in 30 years, but the implementations keep getting better.
The tipping point is when it ceases to matter for most programs, most of the time. We're way past that with VM, and we'll get to that point with memory management too.
Only once the semantics are nailed down. They're not.
And there you jumped from 'object management' to 'memory management'. Which do you mean? They are two very different areas. The latter is pretty well hammered out, but the former doesn't even have a standard formal notation or terminology, much less a denotational semantics that's worth much. And there lies the problem with GC as it currently stands - it tries to map raw memory management techniques onto object management. Doesn't work. Objects add a distinct layer of developer-directed intent and semantics over the top, and any GC system that ignores those is going to hobble the developer using those semantics. Period.
Right now, those semantics are informally learned, passed on, and used as non-selfconscious constructs, to borrow Alexander's term. Because of that, they're seen as fuzzy concepts that people tend to just lump together. They're not, and until they're worked out as distinct programming concepts, and can be supported in languages (or at least libraries), trying to shove that lump under GC is just doing us all a great disservice.
Ah yes, Grumpy Old Man Syndrome
*LOL* Waitaminnit - I get labeled Grumpy Old Man because I'm trying to prepare people for a sea change that hasn't happened yet?
Isn't that a little backwards?
We're *this close* to being able to discuss object management issues *independent of memory management*, and have a solid formal mapping between the two for GCs to play with and work *more* efficiently. Running forward with the current GC model is just going to train programmers to ignore those issues, and we'll never get to where we want to be without another massive re-training effort. Bollocks to that.
At this point, all I can assume is that you're just missing the point. Which is fine, your focus is apparently memory management, not object management. Not surprising, since GC confuses the two already.
Considering the time lag between the Jef Raskin's "Quick Draw Graphics System" dissertation (1969) and the release of the Mac (1984), you'll forgive me for being a bit impatient...
Let's see... 1984 - 1969 = 15 years, I said I was looking at 2020... yup, about right.
Just try not to shoot the rest of us in the foot while you're advocating a stop-gap measure would you? Thanks.
Edit: you know though... it occurs to me that if you can help push for GC everywhere, such that programmers find themselves in a bind with object management, I can swoop in in a decade and make filthy lucre showing them the way out. Muahahahahaha. Go for it!
And there you jumped from 'object management' to 'memory management'. Which do you mean? They are two very different areas. The latter is pretty well hammered out, but the former doesn't even have a standard formal notation or terminology, much less a denotational semantics that's worth much. And there lies the problem with GC as it currently stands - it tries to map raw memory management techniques onto object management.
It's not as bad as all that. VMs like Parrot at least try to separate object destruction from deallocation, use lazy allocation, etc. I think where we differ is that I don't think "a standard formal notation or terminology" and other rigorous academic definitions are required before something useful and worthwhile can be done in the real world. Worse is Better, remember? Unix has been hanging in there, and has been taught quite a few new tricks while we all wait for Hurd or AST's Microkernel OS of the Future or what have you. That's not to say that those things won't come to pass eventually, but in the meantime I'm glad we have what we do.
Let's see... 1984 - 1969 = 15 years, I said I was looking at 2020... yup, about right. Just try not to shoot the rest of us in the foot while you're advocating a stop-gap measure would you? Thanks.
Like I said, forgive me if I'm not willing to stick with malloc() and free() (or even retain/release/autorelease) while I wait until 2020
The free market also doesn't take too kindly to long waits. Getting back to the Copland 2010 thing, what's Apple to say in 2010 when CLR/C#/Java programmers are experiencing real, measurable productivity gains thanks to their languages and environments? "Oh, that stuff's a stop-gap. We'll have the real solution in 2020, just wait!" Shareholders and developers alike won't be too keen on that. The world is a tough old place.
Originally posted by John ]It's not as bad as all that. VMs like Parrot at least try to separate object destruction from deallocation, use lazy allocation, etc. I think where we differ is that I don't think "a standard formal notation or terminology" and other rigorous academic definitions are required before something useful and worthwhile can be done in the real world. Worse is Better, remember? Unix has been hanging in there, and has been taught quite a few new tricks while we all wait for Hurd or AST's Microkernel OS of the Future or what have you. That's not to say that those things won't come to pass eventually, but in the meantime I'm glad we have what we do.
Certainly. Like I said, *I* use a GC'd language daily, and am glad to. I just know when to step in and take over for it though, *because I understand the issues*. Programmers who never get taught the issues because 'it's managed' may be gaining some (where 'some' varies from environment to environment) efficiency for 90% of the code - but then they're frickin' *stuck* when they hit that last 10%. This is when you see all sorts of bizarre schemes get proposed, when all they have to do is turn the GC off for that 10% and do a little handling on their own. (And *why* do they have to turn the GC off? Because it's not smart enough to know how the objects should be treated.)
But that expertise in handling isn't taught or passed down because, well, 'it's managed'. Urk.
Look, we agree that GC is good. We agree that it can lead to some big gains for simple code. Where I think we disagree is where GC needs to go next - in my experience, it breaks down for too many situations that could be easily handled if it would step out of the way, because GC in general is simply not smart enough about developer intent, and the developer has no way of telling the GC what they want, other than 'handle this, don't handle that'. You've got to admit that's pretty damned primitive.
Where are the selections for 'handle that completely', 'treat this as a unique instance, never to be shared, but can be passed around', 'this object is a shared resource, period', and so on? These are higher level abstractions that are necessary for properly discussing even higher level abstractions such as design patterns. Heck, C++ is getting there with the proposed shared_ptr, unique_ptr and so on. It'd be ironic if *C++* leapfrogs C# for object management possibilities, don't you think?
And yet, that conceptually-based approach to object management, making the developer aware of precisely where and how they expecting objects to act, and being able to tell the runtime exactly their intent... that's the future. Not "Are you done with this? I think he's done with this. ANYONE USING THIS? Okay, I'll throw it away... wait... I thought you said you were done with it! Well you didn't *SAY* anything..." which is kind of what memory management is like.
With a clear communication path of intent, it becomes really freaking easy to have safety by default, because the runtime and the developer are in sync over precisely how objects are to be used.
Like I said, forgive me if I'm not willing to stick with malloc() and free() (or even retain/release/autorelease) while I wait until 2020
Gripe, gripe, gripe.
I think there are a number of schemes that could be used - I'll be interested to see what you come up with in article 3.
The free market also doesn't take too kindly to long waits. Getting back to the Copland 2010 thing, what's Apple to say in 2010 when CLR/C#/Java programmers are experiencing real, measurable productivity gains thanks to their languages and environments? "Oh, that stuff's a stop-gap. We'll have the real solution in 2020, just wait!" Shareholders and developers alike won't be too keen on that. The world is a tough old place.
Yup, it is. And free markets have a problem when it comes to looking to the future, no doubt about it. Which is why I'm going to keep advocating *object* management systems that are a wee bit more intelligent than the crop of *memory* management systems we have now. We're almost there, and pushing memory-based management schemes for objects, ala current GC systems, isn't playing catch-up, it's following others down a dead end. At some point, the switchover has to occur, for object-based languages to continue to advance in levels of abstraction. I say lead the way, don't waste resources heading down a path that we already know stops short of where it should.
I mean, you started this with talking about Copland - the poster child for trying to tack things on to an old model if ever there was one. Don't you see that current GCs are the model on which ever more layers of cruft are getting tacked? They're going to collapse under their own weight at some point, and I don't think that day is too far off, when the semantics of the GC, not the performance, become what holds the languages and the developers back.
I think Obj-C and Cocoa are in a decent position right now for adding a serious object management system, and leapfrogging the memory management approaches used in current GCs. That would leave CLR/C# playing catch-up not in 2020, but in 2010. Much nicer, no?
And, I think it could be done without breaking the current code. Hmmm. Blast you, now you have me thinking about something other than my defense. *shakes fists*
Originally posted by John
In the case of VM, the semantics have constantly been redefined in subtle and not-so-subtle ways. Compare the VM implementation of Linux, Mac OS X, classic Mac OS, Window NT 4, and Windows 95. The tipping point is when it ceases to matter for most programs, most of the time. We're way past that with VM, and we'll get to that point with memory management too.
The real tipping point for VM was after the semantics were solid enough to allow for design of appropriate dedicated hardware to generate the needed speed. Before that VM was a nice topic for dissertations, but too slow to be universally considered for mandatory use. After VM hardware was designed and operating properly, the programmer's need to manually maintain overlays went away. Not only was maintaining overlays hard, but it was too slow compared to the new solution. Note this is very different from you prediction that future simple speed increases in hardware will automagically make us unconcerned with the performance hit. The memory managed API process is still in software, and still sapping performance.
Another huge reason for system wide VM to which enforced memory managed API's have no equivalent is multiprogramming. VM allows many programs to play nice simultaneously having the OS play traffic cop. Memory management schemes in the context of your article have effects limited to the interior to a single program. There is no analogous common exterior driving force to VMs solution as a way to efficiently share the machines physical resources. Not to mention that within the year, 4 of the 5 OSes you cited with diferent VM implementations will al be using their individual implementations on top of the identical paging hardware support on the same CPU [Only Classic is left out in the cold]. The semantics aren't nearly as different as you would lead others to believe.
I don't see dedicated hardware figuring into garbage collection/managed memory ops in the near-to-mid term to save the speed hit that currently drives non-deterministic garbege collected program execution timelines.
Look, we agree that GC is good. We agree that it can lead to some big gains for simple code. Where I think we disagree is where GC needs to go next - in my experience, it breaks down for too many situations that could be easily handled if it would step out of the way, because GC in general is simply not smart enough about developer intent, and the developer has no way of telling the GC what they want, other than 'handle this, don't handle that'. You've got to admit that's pretty damned primitive.
See, I think that's a problem with the feature set of the language, not of the GC implemented to support it.
Where are the selections for 'handle that completely', 'treat this as a unique instance, never to be shared, but can be passed around', 'this object is a shared resource, period', and so on?
Actually, maybe we disagree on terminology. Why isn't a language implementation that includes the feature as you describe above still "garbage collected"? Because the language supports hints that a garbage collector could use in its implementation? I don't limit GC to just "dumb memory tracking for dumb languages." Garbage collectors get smarter all the time, and languages are getting smarter with them. It's parallel evolution.
Some strategies and some combinations are going to be losers, but the ones that work will continue the line, so to speak. The sometimes-loose coupling (probably too loose for your tastes) between language features and the GC implementation will actually help in the early years of this transition because loser GCs can be swapped out for better ones. Just look at the evolution of Java VMs. They've come a long way in a short time, with the best of the best give C/C++ a run for the money in some tasks.
"Are you done with this? I think he's done with this. ANYONE USING THIS? Okay, I'll throw it away... wait... I thought you said you were done with it! Well you didn't *SAY* anything..."
I'll just add that there's a built-in assumption that this kind of mistake on the part of the memory management system is important. Long term, it won't be. And in the interim, there are already ways to signal things like "hey, keep this around because I'm going to need it shortly" and "throw this away, I'm done with it now." They may be primitive (keep a reference, weaken a reference, control scope) but they do exist and are actually used today.
I think there are a number of schemes that could be used - I'll be interested to see what you come up with in article 3.
I doubt you will, since I'll be talking a lot about existing high-level languages and APIs, and pretty much not at all about stuff that doesn't exist yet, but would be even better if it did
I'm going to keep advocating *object* management systems that are a wee bit more intelligent than the crop of *memory* management systems we have now.
See, I don't think this distinction is very meaningful at anything below the language level, and plenty of high-level languages already think of resource management in terms of objects.
I mean, you started this with talking about Copland - the poster child for trying to tack things on to an old model if ever there was one. Don't you see that current GCs are the model on which ever more layers of cruft are getting tacked?
No, I see them as a replaceable engine upon which increasingly abstracted languages can run (and run increasingly better, if all goes well).
I think Obj-C and Cocoa are in a decent position right now for adding a serious object management system, and leapfrogging the memory management approaches used in current GCs. That would leave CLR/C# playing catch-up not in 2020, but in 2010. Much nicer, no? And, I think it could be done without breaking the current code.
If you have a plan for this, I'm sure Apple would like to hear it. But I wonder what you're going to do about the pointer situation, C/C++ compatibility, and all that jazz.
The real tipping point for VM was after the semantics were solid enough to allow for design of appropriate dedicated hardware to generate the needed speed [...] Note this is very different from you prediction that future simple speed increases in hardware will automagically make us unconcerned with the performance hit.
I never said anything about the simplicity of the performance increases that will eventually render GC performance a non-issue. I doubt it will be dedicated hardware, but I don't rule it out either. It could just as easily simply be a huge surplus of fast memory. But my bet is that the advantages of managed memory will outweigh the performance pitfalls long before all the performance issues disappear entirely. In some areas, some would say that's already happened. Certainly MS and Sun seem to think so.
Originally posted by John
See, I think that's a problem with the feature set of the language, not of the GC implemented to support it.
The two go hand in hand, as I stated - we need better object management, *AND* better ways to tell the underlying technology (GC, for lack of a better term) what we want. That's where the language comes in.
Like I said, I don't think we're that far off on this.
Actually, maybe we disagree on terminology. Why isn't a language implementation that includes the feature as you describe above still "garbage collected"? Because the language supports hints that a garbage collector could use in its implementation? I don't limit GC to just "dumb memory tracking for dumb languages." Garbage collectors get smarter all the time, and languages are getting smarter with them. It's parallel evolution.
Yup, it is. *Current* GCs mangle memory management with object management badly. I don't see that changing until the language support is there to communicate intent, and until there's a solid definition for at least some of the object semantics. Whether you call it GC, OC, or Fortran, it's still the same basic principle - taking care of things the developer is done with.
Some strategies and some combinations are going to be losers, but the ones that work will continue the line, so to speak. The sometimes-loose coupling (probably too loose for your tastes) between language features and the GC implementation will actually help in the early years of this transition because loser GCs can be swapped out for better ones. Just look at the evolution of Java VMs. They've come a long way in a short time, with the best of the best give C/C++ a run for the money in some tasks.
Actually, a good semantics allows for the implementation to be swapped out more easily, because the requirements for the interface are better understood. Like I said, I think the next big leap is going to be GCs that are object *intent* aware, not just object aware.
I'll just add that there's a built-in assumption that this kind of mistake on the part of the memory management system is important. Long term, it won't be. And in the interim, there are already ways to signal things like "hey, keep this around because I'm going to need it shortly" and "throw this away, I'm done with it now." They may be primitive (keep a reference, weaken a reference, control scope) but they do exist and are actually used today.
EXACTLY! *BING BING BING* WHOOHOO!
That's been pretty much my point all along, that *THAT* is where the push for GCs needs to be - communicating intent to the GC subsystem, by making the bloody thing more intelligent about object management.
Saying that "Well, it's primitive, so let's get rid of it" isn't the approach to take. I don't think that's what you're advocating, but god knows I've run into more than one yahoo who thought that way. It's primitive, sure, but it's the place to be focussing the effort.
Unfortunately, the current state of the art in GC seems to be going in the other direction.
I doubt you will, since I'll be talking a lot about existing high-level languages and APIs, and pretty much not at all about stuff that doesn't exist yet, but would be even better if it did
Naw, it'll be fun to see how close you get.
See, I don't think this distinction is very meaningful at anything below the language level, and plenty of high-level languages already think of resource management in terms of objects.
For some things, no, it's not important - but as you increase abstraction, you need to increase language support for same. Object management is one heck of an abstraction that hasn't really been addressed past the syntactic level in most languages, and that's at best.
No, I see them as a replaceable engine upon which increasingly abstracted languages can run (and run increasingly better, if all goes well).
You can pull out the guts of the engine, but until the engine starts treating object management as something more than raw chunks of memory that are either active or not, the situation isn't going to change appreciably. All you're doing there is making a semi-intelligent engine even faster at being semi-intelligent.
Unfortunately, as we've both been saying, without support at the language level, the code can't provide the engine with the information it needs. So right now we're in a chicken and egg situation - no one is going to adopt a brand spanking new language with new keywords that can't be really well implemented on the backend, and no one is going to put the effort into working on that backend without a practical language with developers.
If you have a plan for this, I'm sure Apple would like to hear it. But I wonder what you're going to do about the pointer situation, C/C++ compatibility, and all that jazz.
I thought we were talking about objects?
Seriously, one of the nice things about Obj-C is that it's utterly schizo - the object model and the procedural model are damned near partitioned. Some people hate it, I love it, because it allows each model to be quite 'pure', but interconnected. It's like being able to jump between Smalltalk and C at will to use each for the things it does best. The only place where schemes for solid object management are going to be possible are on the object side, obviously. If you look at most Obj-C code, it's quite well separated into object and procedural parts. GC for procedural systems is actually closer to the theoretical limits of the language abstractions than on the object side. I say let the two sides handle their own issues in the ways they know best. The amount of overlap is generally very small, and the underlying bridge (aha!) in the runtime is the appropriate place to handle boundary issues.
Originally posted by John
I never said anything about the simplicity of the performance increases that will eventually render GC performance a non-issue. I doubt it will be dedicated hardware, but I don't rule it out either. It could just as easily simply be a huge surplus of fast memory. But my bet is that the advantages of managed memory will outweigh the performance pitfalls long before all the performance issues disappear entirely. In some areas, some would say that's already happened. Certainly MS and Sun seem to think so.
I know you didn't directly say anything about simplicity, but your point that speed increases alone will compensate adequately for the performance issues IS a simple solution to the problem. I just don't agree that is enough, by a long shot, for enforced full time memory managment/GC. And further distance that possibility by showing your VM example was not cleanly analogous because it required a non-trivial infusion of dedicated hardware to become ubiquitous today, something a simple speed-up of CPUs will not offer MM/GC.
I personally agree with the lions share of what Kickaha is saying, he can put it a lot more eloquently and precicely that I can, being in his personal scope of interest. In my short version it is "Choice is good", and I see the addition of sane GC to Obj-C a likely good middle ground solution, not half-baked and dooming OS X to Copland-like obscurity in the future. Sure, the execution could end up screwed, but then that isn't the idea's fault but the implementation's, and we won't know that until it is unveiled.
I would sit back and watch, go ahead and mention some potential pitfalls, but not universally condemn up front using highly loaded examples like a failed Copeland project. That's just trolling for hits and goes back to my current bias against Ars generated from several years of hanging around that community and seeing the changes I'm not happy with. And by my dictionary, bias is only "usually unfair". So biased I am, and personally and ego diven as it may be, see my bias as fitting in the exception delinated by that little word usually. If you or anyone else think it's unfair, it doesn't break my heart. But do notice, even though we have been in strong disagreement, this isn't a barely-shrouded-profanity laden flamefest.