I don't think that adding generics requires a change to the bytecode. IIRC, Java generics are actually just a pre-processing of the source to apply the correct type at compile time. The end result is that, at the bytecode level, nothing changes.
In many ways, I am actually for something of this nature. Runtime typecasting isn't the most efficient use of processor time, and this pushes back the type check to compile time. All in all, this should be a Good Thing.
I could be off my rocker on this one though. I have nothing to cite, and I'm only going by what appears in this strange thing I call my memory.
Oh, that's easy- people listen to Diamanda Galas so they can be pretentious. It's the same reason people claim to listen to Swans before, say, This Burning World.
Heh...I once saw a concert poster from Swans' early days. It said..."Tonight! Live! The Smiths with special guest: Swans!" I tried to picture a venue full of Swans fans and Smiths fans. I laughed so hard that I hurt myself.
Does the call to System.GC.Collect block until completion of the GC's deallocation run, or does it just heavily prioritize the GC and return right away? I'm just curious.
I tend to view things from what kind of development work that I do, and that does not include web app development -- from the perspective you're looking at things from, thrashing the gc is probably a more frequent problem.;)
Actually, what I'm looking at isn't web apps. It's application servers. Those are even more memory intensive. Memory issues and GC thrashing really show up on any large project I've seen. Even something that doesn't look big, like an IDE, can have this problem. I've written literally dozens of apps and lightweight frameworks that never worry about memory management, though.
Unfortunately, nothing is perfect.
Bah. Perfection is overrated and boring. If things were already perfect, I'd never get to think about how I could make stuff better.;)
After a little more research, I'd like to add a few things. First off, I'll believe that.NET timeouts its finalizers, but the Sun JVM implementation of the JVM spec doesn't. You can contact me privately (wlightATweatherlightDOTcom) for my example code, but I have a finalizer that will never return and keep a running tally of its time. It's still alive after 600 secs. Yes, indeed, it does prevent other finalizers from being run. Again, contact me privately for my source code.
It doesn't "halt" the GC, though. The GC is in charge of both allocs and deallocs, and it continues to work fine for allocs. I can't really see if it's continuing to deallocate and skipping finalizers or what, though. I really need to create tests that run for longer before I can say for sure. If the deallocator had stopped, the free memory count should decrease over time proportional to object creation. It kinda looks like that happens, but I'm not sure as of yet.
That said, though, there's no reason you need a simple timeout to prevent a simple while(true) loop from taking out the deallocator. All you need is a more appropriate threading strategy for your deallocator. The safest, but most expensive, technique is to use a separate thread for each finalizer. Other options are to allow concurrent deallocator runs in separate threads. Yes, you still need to eventually "pull the plug" on wayward finalizer threads or you have a thread leak, but that's different than having a static time limit on finalization.
So, yes, Java (or, at least, the Sun JVM) can't guarantee it'll get around to running a finalizer, and IIRC, it has a similar shutdown timeout to what I've seen.NET having. Whether or not a constant, static timeout for finalizers is necessary to save your GC remains to be seen, though. Personally, I'm all for giving finalizers as long as they need and working around that premise in designing my GC. I may be overly conservative in my design, though. 99% of all objects created will not have specialized finalizers, and my way of thinking therefore probably hurts the average case.
I really do appreciate this exchange. If you ever feel like emailing me and talking more, my address is in this post.
I agree in the general case to what you're saying. I myself have been a fan of a runtime garbage collector managing all memory activities for a while now. What I do believe, though, is that that's not an end-all answer, either. Yes, it is for applications development on a desktop PC where memory use isn't generally a problem.
But let's skip.NET for a second and look at what people are doing with Java. JBoss, an open source J2EE server, is a massive application (when you're using all the J2EE stuff, anyway). There's a constant concern on their developers list about "thrashing", a state where the garbage collector's activity, no matter how frequent, doesn't satisfy memory needs. Memory reclamation and allocation for short-term use are just that coincidentaly. I can't help but feel that situations like this could be better alleviated if some sort of just-in-time memory recycling were possible. This is what I was alluding to when I talked about future runtime environments and the possibility of allowing programmers to decide how much involvement the GC has.
Again, I agree totally that, most of the time and for most cases, living under the GC is a Good Thing. I disagree with your 99%/1% comparison, though, because that depends entirely on what you're writing and for what kind of system. I'm talking in generalities. I'm not talking about just in.NET.
Okay...I believe you. All I'm saying is the only place I see that time limit enforced is on runtime shutdown. If what you say is true,.NET finalizers would fall under "wretched" in my book.
Appreciated! The majority of what I know about.NET comes from reading ECMA-335, as I'm interested in the runtime internals more than anything else, and I don't know nearly as much about programming with, say, C#.
Having a garbage collector means you don't have to care about memory management and optimization. In fact, odds are that the memory management code can do a better job of optimizing memory usage than your own code can.
Generally speaking, yes, I agree with you, especially when talking about application software.
It can compress the memory store when things get tight (something very difficult to do with unmanaged code), but when things arn't tight it doesn't have to waste time constantly allocating/releasing tiny blocks of memory.
Also agreed. You definitely have the benefits of GC down pat. I wouldn't disagree.
If you're in the corner case where you've got a small of memory to work with and you're trashing the GC, then yeah, writing an app in managed code is NOT a great idea. On a modern computer it isn't an issue.
Modern doesn't mean you're not in a "corner case", though. Memory-intensive software in a large memory space is a "corner case", and an increasing number of "modern" applications are appearing on embedded systems with extremely limited memory.
Oh, I know that dodging fixed pointers, pinned stuff, and blocks of unsafe code is a drain on the runtime. I wouldn't do it if I didn't need to. I'm pointing out, though, that the option to do so exists, so there is some degree of manual memory management in.NET and it's not 100% dominated by the GC.
Looking around, I see where there is a 2sec/finalzer and 40sec/(all finalizers) limit during the shutdown of a.NET runtime. I don't see where that time limit is enforced anywhere else, though.
1) It's my understanding that at least C# allows for a deterministic finalizer method, though it's not a true destructor. In a lot of circles, "destructor" and "finalizer" are used interchangably, and I have lamentably fallen prey to that habit.
2) I don't recall seeing that time limit in the ECMA standard for the runtime. I will be happy to review it when I get home (it's hard to dig through the PDF while I'm at work) and give a second comment on it. If a constant amount of time were given for all finalizers to run in, that would be a severe shot in the foot of the memory manager. As far as I'm aware, a JVM will allow all finalizers to run every time...even if a finalizer deadlocks, it's allowed to finish (though it never will), BTW.
Additionally, while this is a.NET discussion, the inclusion of "like Java" in the parent suggests to me we're talking about issues of surrendering programmer control to a runtime garbage collector, not specifically just.NET or Java.
I hear a lot of complaints about the lack of deterministic finalization, but I really have to wonder why people care so much about when the memory is actually freed for a particular object.
Technically, you're talking about two different things. Finalization is the "end of lifecycle" processing of an object, beyond which the object becomes semantically meaningless. Removal from memory of the "dead bytes" of that object is something different. The reason people often complain about deterministic finalization is because, without it, you have no control over when the object's cleanup happens. You know you don't need that object anymore, but you can't actually get rid of it. That can be annoying, especially if you come from a C or C++ background and are very much accostumed to being able to control everything.
Being able to control finalization and memory frees (which are technically not coupled in Java or.NET memory managed code) can also be really important when you're either in a small memory space (J2ME) or you're writing server software like a J2EE container. The reason why is because, bascially, you're replacing your intimate knowledge of your own software with some best-guess heuristics. There's little I know of that's worse than a thrashing GC, and this can be avoided if you can micromanage memory collection to happen at more opportune times. Some JVMs (Sun's, most notably) allow you to tune their GCs to help prevent this through a control of the amount of memory given to objects of different ages. This can be quite helpful in performance tuning.
If you have some clean-up that needs to happen, put it into a Dispose() method and call it yourself. Pretty simple.
I don't know enough about.NET to comment, but if there's an interface you can implement to provide uniformity in the call and use of that method, that's great. Java, AFAIK, has no such interface, so hand-made deterministic cleanup is idiosyncratic. That's okay, but it's not ideal. What's more, though, let me ask you this- in some large middleware or object framework following your idea, what guarantee is there that your disposal method won't accidentally get called twice? This could lead to indeterminate states in the system that aren't immediately understood, since there's no check against that implicit. At least with a C++ destructor, destroying the object guarantees that further use of the object is impossible. No such guarantee is available with homespun management. Yes, the roll-your-own you're describing is good enough, but that doesn't mean it's without flaw.
...who cares? Just let go of your reference and let the GC handle it. You've executed your cleanup code, so why do you care that there is a block of memory out there that you can't even see that's still allocated? It's not going to leak, so just let the GC do it's job.
Maybe, but again, think about situations where you're trying to minimize memory use. Deterministic destruction makes memory immediately available again. You can put a new object in that freshly freed memory. With a GC, that may not be possible. Thus, I dispose() my object, which scrubs it clean, then I throw it to the wolves...only they're not hungry just yet. I go to make a new object, and that memory isn't available. On most systems, this will force the GC to mark the dereferenced object's memory as fair game, yes, so this isn't a big big deal, but the decoupling described can lead to ickiness. Also, as I mentioned, having memory deallocation occur synchronously to my call to a destructor means the GC will never thrash. GC thrashing seriously slows a program down, and after thrashing and thrashing, it still might not have the memory you're looking for (for various reasons).
In my experience, the loss of control that results from being in a GC environment is neither as big a deal as its oponents make it out to be, nor is it as little a deal as its proponents make it out
Yes, but what about the options in C# that allow you to work with pointers? Isn't raw memory managment the reason for the "unsafe" keyword?
According to ECMA-334, unsafe code is "code that is permitted to perform such lower-level operations as declaring and operating on pointers, performing conversions between pointers and integral types, and taking the address of variables. Such operations provide functionality such as permitting interfacing with the underlying operating system, accessing a memory-mapped device, or implementing a time-critical algorithm."
Surely one is allowed to engage in one's own memory managment in unsafe code blocks without the GC's "help."
I do assure you that applications written in C# running on the.NET platform will outperform Java applications running on any JVM in most cases.
Your assurances would have more thrust if they involved some hard numbers.
Many JVM's use JIT compilation techniques. They just don't work as well as.NET. I am sorry, but Java is slow, on any JVM I know of.
I have heard anecdotal evidence, mostly from Mono project types, that CIL is easier to apply JIT optimizations to than Java bytecode. Having written a bytecode loader and verifier, I might believe this, since I have found most of classloading (especially dealing with attributes) to be annoying at best. Again, though, your arguments would be better served if you had more than your personal impressions available.
Note:
I don't particulary like Microsoft in general, and the bulk of my professional development is done in Java. I do think that the.NET platform is the best M$ has produced since... well ever.
I would tend to agree, but at the same time, this doesn't say a hell of a lot about previous APIs from MS more than anything.
Don't knock.NET until you have tried it!
I have, and I have programmed in it, and I've read quite a bit of Mono's source code, and I own and have read most of a copy of ECMA-335. Additionally, you'll see that nowhere in anything I wrote did I actually "knock".NET.
Thanks to JIT it is much, *much* faster than Java. The only thing Java has going for it here is platform independence and the huge libraries.
There is no such thing as it being "faster than Java". The MS CLI implementation may be able to outpace a certain JVM on certain activities, but don't confuse a JVM with Java. There's a fundamental difference. I can get radically different performance on the same Java program from different VMs.
Also, do you really think that the major JVMs don't use JIT compilation techniques?
Not exactly. In.NET you can release objects so that your own program can no longer access them in memory, but you still have to wait for the automatic garbage collection to really clean it up. You really have no true control over garbage collection in.NET; you can only influence it somewhat.
Even when you do raw pointer manipulation in an an unsafe block of code? I thought that the point of pinned pointers and the "unsafe" keyword in C# was so that you could engage in direct memory managment in limited scopes. Pointer pins keep the GC from moving your stuff around and the unsafe block turns off the manager for local scopes, no? So, shouldn't this allow you to hand-manage some memory?
...and just like in Java, that control is less than perfect.
On the contrary, you have zero memory control in Java unless you use Java objects as JNI wrappers and then do all your memory managment in C. Alternately, you can use JVMPI to trap memory allocs and deallocs and try to control things that way. Or you find a VM that lets you tune and reprogram GC behavior. All objects in Java are subject to the GC. In.NET, there is some support for hand-managed memory, though attempts to limit it exist.
If I remember correctly there is, for example, no way to guarantee a destructor will run for a particular instance before it is recycled.
Is this still true?
It was never true. You're guaranteed that finalize() will run on an object before it is removed from memory. What you're not guaranteed is that the object will ever be the target of a collection, meaning finalize() might never run. Additionally, it's impossible to know at what point in time after the running of finalize() (if ever) the object will actually be taken out of memory.
Thanks for the info. I appreciate it.;)
As far as "innovative" and how it applies more to use and applications, perhaps innovation is like beauty...best left in the eye of the beholder.
Uh...what about the O(1) scheduler? I think I read on KernelTrap that soon you'll be able to hotswap schedulers at runtime, too. What about the anticipatory I/O scheduler?
I'm not certain, so correct me if I'm wrong. Are none of these things innovative?
Slashdot Mirror
...especially since the assert keywork is, on Sun's JDK, only compiled to a bytecode construct if you request it be at compile-time.
In many ways, I am actually for something of this nature. Runtime typecasting isn't the most efficient use of processor time, and this pushes back the type check to compile time. All in all, this should be a Good Thing.
I could be off my rocker on this one though. I have nothing to cite, and I'm only going by what appears in this strange thing I call my memory.
Oh, that's easy- people listen to Diamanda Galas so they can be pretentious. It's the same reason people claim to listen to Swans before, say, This Burning World.
Heh...I once saw a concert poster from Swans' early days. It said..."Tonight! Live! The Smiths with special guest: Swans!" I tried to picture a venue full of Swans fans and Smiths fans. I laughed so hard that I hurt myself.
I mean "Who actually considers that song to be proto-goth?"
And I don't recall Bart performing that song. I recall Gladys, the organ lady from Rev. Lovejoy's church, being the artist on that one.
I see, so successfully deciphering the meaning behind The Sisters of Mercy's "This Corrosion" is left for a graduate level course?
*boggle* By whom?
Does the call to System.GC.Collect block until completion of the GC's deallocation run, or does it just heavily prioritize the GC and return right away? I'm just curious.
Actually, what I'm looking at isn't web apps. It's application servers. Those are even more memory intensive. Memory issues and GC thrashing really show up on any large project I've seen. Even something that doesn't look big, like an IDE, can have this problem. I've written literally dozens of apps and lightweight frameworks that never worry about memory management, though.
Unfortunately, nothing is perfect.
Bah. Perfection is overrated and boring. If things were already perfect, I'd never get to think about how I could make stuff better. ;)
It doesn't "halt" the GC, though. The GC is in charge of both allocs and deallocs, and it continues to work fine for allocs. I can't really see if it's continuing to deallocate and skipping finalizers or what, though. I really need to create tests that run for longer before I can say for sure. If the deallocator had stopped, the free memory count should decrease over time proportional to object creation. It kinda looks like that happens, but I'm not sure as of yet.
That said, though, there's no reason you need a simple timeout to prevent a simple while(true) loop from taking out the deallocator. All you need is a more appropriate threading strategy for your deallocator. The safest, but most expensive, technique is to use a separate thread for each finalizer. Other options are to allow concurrent deallocator runs in separate threads. Yes, you still need to eventually "pull the plug" on wayward finalizer threads or you have a thread leak, but that's different than having a static time limit on finalization.
So, yes, Java (or, at least, the Sun JVM) can't guarantee it'll get around to running a finalizer, and IIRC, it has a similar shutdown timeout to what I've seen .NET having. Whether or not a constant, static timeout for finalizers is necessary to save your GC remains to be seen, though. Personally, I'm all for giving finalizers as long as they need and working around that premise in designing my GC. I may be overly conservative in my design, though. 99% of all objects created will not have specialized finalizers, and my way of thinking therefore probably hurts the average case.
I really do appreciate this exchange. If you ever feel like emailing me and talking more, my address is in this post.
But let's skip .NET for a second and look at what people are doing with Java. JBoss, an open source J2EE server, is a massive application (when you're using all the J2EE stuff, anyway). There's a constant concern on their developers list about "thrashing", a state where the garbage collector's activity, no matter how frequent, doesn't satisfy memory needs. Memory reclamation and allocation for short-term use are just that coincidentaly. I can't help but feel that situations like this could be better alleviated if some sort of just-in-time memory recycling were possible. This is what I was alluding to when I talked about future runtime environments and the possibility of allowing programmers to decide how much involvement the GC has.
Again, I agree totally that, most of the time and for most cases, living under the GC is a Good Thing. I disagree with your 99%/1% comparison, though, because that depends entirely on what you're writing and for what kind of system. I'm talking in generalities. I'm not talking about just in .NET.
Okay...I believe you. All I'm saying is the only place I see that time limit enforced is on runtime shutdown. If what you say is true, .NET finalizers would fall under "wretched" in my book.
Appreciated! The majority of what I know about .NET comes from reading ECMA-335, as I'm interested in the runtime internals more than anything else, and I don't know nearly as much about programming with, say, C#.
Generally speaking, yes, I agree with you, especially when talking about application software.
It can compress the memory store when things get tight (something very difficult to do with unmanaged code), but when things arn't tight it doesn't have to waste time constantly allocating/releasing tiny blocks of memory.
Also agreed. You definitely have the benefits of GC down pat. I wouldn't disagree.
If you're in the corner case where you've got a small of memory to work with and you're trashing the GC, then yeah, writing an app in managed code is NOT a great idea. On a modern computer it isn't an issue.
Modern doesn't mean you're not in a "corner case", though. Memory-intensive software in a large memory space is a "corner case", and an increasing number of "modern" applications are appearing on embedded systems with extremely limited memory.
Oh, I know that dodging fixed pointers, pinned stuff, and blocks of unsafe code is a drain on the runtime. I wouldn't do it if I didn't need to. I'm pointing out, though, that the option to do so exists, so there is some degree of manual memory management in .NET and it's not 100% dominated by the GC.
Looking around, I see where there is a 2sec/finalzer and 40sec/(all finalizers) limit during the shutdown of a .NET runtime. I don't see where that time limit is enforced anywhere else, though.
2) I don't recall seeing that time limit in the ECMA standard for the runtime. I will be happy to review it when I get home (it's hard to dig through the PDF while I'm at work) and give a second comment on it. If a constant amount of time were given for all finalizers to run in, that would be a severe shot in the foot of the memory manager. As far as I'm aware, a JVM will allow all finalizers to run every time...even if a finalizer deadlocks, it's allowed to finish (though it never will), BTW.
Additionally, while this is a .NET discussion, the inclusion of "like Java" in the parent suggests to me we're talking about issues of surrendering programmer control to a runtime garbage collector, not specifically just .NET or Java.
Technically, you're talking about two different things. Finalization is the "end of lifecycle" processing of an object, beyond which the object becomes semantically meaningless. Removal from memory of the "dead bytes" of that object is something different. The reason people often complain about deterministic finalization is because, without it, you have no control over when the object's cleanup happens. You know you don't need that object anymore, but you can't actually get rid of it. That can be annoying, especially if you come from a C or C++ background and are very much accostumed to being able to control everything.
Being able to control finalization and memory frees (which are technically not coupled in Java or .NET memory managed code) can also be really important when you're either in a small memory space (J2ME) or you're writing server software like a J2EE container. The reason why is because, bascially, you're replacing your intimate knowledge of your own software with some best-guess heuristics. There's little I know of that's worse than a thrashing GC, and this can be avoided if you can micromanage memory collection to happen at more opportune times. Some JVMs (Sun's, most notably) allow you to tune their GCs to help prevent this through a control of the amount of memory given to objects of different ages. This can be quite helpful in performance tuning.
If you have some clean-up that needs to happen, put it into a Dispose() method and call it yourself. Pretty simple.
I don't know enough about .NET to comment, but if there's an interface you can implement to provide uniformity in the call and use of that method, that's great. Java, AFAIK, has no such interface, so hand-made deterministic cleanup is idiosyncratic. That's okay, but it's not ideal. What's more, though, let me ask you this- in some large middleware or object framework following your idea, what guarantee is there that your disposal method won't accidentally get called twice? This could lead to indeterminate states in the system that aren't immediately understood, since there's no check against that implicit. At least with a C++ destructor, destroying the object guarantees that further use of the object is impossible. No such guarantee is available with homespun management. Yes, the roll-your-own you're describing is good enough, but that doesn't mean it's without flaw.
Maybe, but again, think about situations where you're trying to minimize memory use. Deterministic destruction makes memory immediately available again. You can put a new object in that freshly freed memory. With a GC, that may not be possible. Thus, I dispose() my object, which scrubs it clean, then I throw it to the wolves...only they're not hungry just yet. I go to make a new object, and that memory isn't available. On most systems, this will force the GC to mark the dereferenced object's memory as fair game, yes, so this isn't a big big deal, but the decoupling described can lead to ickiness. Also, as I mentioned, having memory deallocation occur synchronously to my call to a destructor means the GC will never thrash. GC thrashing seriously slows a program down, and after thrashing and thrashing, it still might not have the memory you're looking for (for various reasons).
In my experience, the loss of control that results from being in a GC environment is neither as big a deal as its oponents make it out to be, nor is it as little a deal as its proponents make it out
According to ECMA-334, unsafe code is "code that is permitted to perform such lower-level operations as declaring and operating on pointers, performing conversions between pointers and integral types, and taking the address of variables. Such operations provide functionality such as permitting interfacing with the underlying operating system, accessing a memory-mapped device, or implementing a time-critical algorithm."
Surely one is allowed to engage in one's own memory managment in unsafe code blocks without the GC's "help."
Your assurances would have more thrust if they involved some hard numbers.
Many JVM's use JIT compilation techniques. They just don't work as well as .NET. I am sorry, but Java is slow, on any JVM I know of.
I have heard anecdotal evidence, mostly from Mono project types, that CIL is easier to apply JIT optimizations to than Java bytecode. Having written a bytecode loader and verifier, I might believe this, since I have found most of classloading (especially dealing with attributes) to be annoying at best. Again, though, your arguments would be better served if you had more than your personal impressions available.
Note: I don't particulary like Microsoft in general, and the bulk of my professional development is done in Java. I do think that the .NET platform is the best M$ has produced since... well ever.
I would tend to agree, but at the same time, this doesn't say a hell of a lot about previous APIs from MS more than anything.
Don't knock .NET until you have tried it!
I have, and I have programmed in it, and I've read quite a bit of Mono's source code, and I own and have read most of a copy of ECMA-335. Additionally, you'll see that nowhere in anything I wrote did I actually "knock" .NET.
There is no such thing as it being "faster than Java". The MS CLI implementation may be able to outpace a certain JVM on certain activities, but don't confuse a JVM with Java. There's a fundamental difference. I can get radically different performance on the same Java program from different VMs.
Also, do you really think that the major JVMs don't use JIT compilation techniques?
Even when you do raw pointer manipulation in an an unsafe block of code? I thought that the point of pinned pointers and the "unsafe" keyword in C# was so that you could engage in direct memory managment in limited scopes. Pointer pins keep the GC from moving your stuff around and the unsafe block turns off the manager for local scopes, no? So, shouldn't this allow you to hand-manage some memory?
On the contrary, you have zero memory control in Java unless you use Java objects as JNI wrappers and then do all your memory managment in C. Alternately, you can use JVMPI to trap memory allocs and deallocs and try to control things that way. Or you find a VM that lets you tune and reprogram GC behavior. All objects in Java are subject to the GC. In .NET, there is some support for hand-managed memory, though attempts to limit it exist.
If I remember correctly there is, for example, no way to guarantee a destructor will run for a particular instance before it is recycled. Is this still true?
It was never true. You're guaranteed that finalize() will run on an object before it is removed from memory. What you're not guaranteed is that the object will ever be the target of a collection, meaning finalize() might never run. Additionally, it's impossible to know at what point in time after the running of finalize() (if ever) the object will actually be taken out of memory.
Thanks for the info. I appreciate it. ;)
As far as "innovative" and how it applies more to use and applications, perhaps innovation is like beauty...best left in the eye of the beholder.
I'm not certain, so correct me if I'm wrong. Are none of these things innovative?
The product to which I was referring did not come on CD nor was it sold with a CD.