 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / December 2004Clearing memory from instantiated objects
Hi, Is it possible to remove a specific object (instantiated) whilst the running a program. I'm writing a highly repeatative task and dont want to suck the systems memory having old information stored in the memory. Thanks for any help, Jon > Hi, > > Is it possible to remove a specific object (instantiated) whilst the > running a program. I'm writing a highly repeatative task and dont want > to suck the systems memory having old information stored in the memory. > Thanks for any help, Jon If you use the same name for the result variable or something like that you don't need to worry about memory leaks; The variable is overwritten. If you use other names the Java Virtual Machine will decide when Objects aren't used anymore and dispose of them when it likes. If you are about to execute a long and memory intensive task, you might do "System.gc();" before (and after) it. That manually starts the garbage collection (the process described in the above paragraph), but it is not recommended for 'normal' programs, which almost every program is.  Signature------------- - ByteCoder - ...I see stupid people ------------- Curiosity *Skilled* the cat Hi, Thanks very much for your help, it was very helpful! Thanks again, Jon It wasn't in fact. It was very untrue. SignatureTony Morris http://xdweb.net/~dibblego/ > Hi, > > Thanks very much for your help, it was very helpful! > Thanks again, Jon > > Hi, > > [quoted text clipped - 5 lines] > If you use the same name for the result variable or something like that > you don't need to worry about memory leaks; The variable is overwritten. This is not even close to true. > If you use other names the Java Virtual Machine will decide when Objects > aren't used anymore and dispose of them when it likes. [quoted text clipped - 3 lines] > garbage collection (the process described in the above paragraph), but > it is not recommended for 'normal' programs, which almost every program is. It doesn't. It makes a suggestion to run the garbage collector. This seldom occurs in practice - that is, your suggestion is seldom honoured by the gc. To call gc is general poor form - an attempt to deviate from the already complicated algorithms used by the garbage collector undermines the value provided at best. Google is the best choice for you and the OP. The answer to the original question is, "you can't, you don't, and to want to suggests you have deeper problems." In this case, it helps to state the real requirement, not a broken solution. Merry Christmas. SignatureTony Morris http://xdweb.net/~dibblego/ > It doesn't. > It makes a suggestion to run the garbage collector. > This seldom occurs in practice - that is, your suggestion is seldom honoured > by the gc. I used to hear this term "suggestion" in C++ by people describing how "inline" functions work. It's wrong. It's not a suggestion. It's a request. > To call gc is general poor form - an attempt to deviate from the already > complicated algorithms used by the garbage collector undermines the value > provided at best. If it "undermined the value provided at best", then the function would never have been provided in the first place. It's there for a reason. > > It doesn't. > > It makes a suggestion to run the garbage collector. [quoted text clipped - 5 lines] > "inline" functions work. It's wrong. It's not a suggestion. It's a > request. You can take that argument up with the specification: "Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse." > > To call gc is general poor form - an attempt to deviate from the already > > complicated algorithms used by the garbage collector undermines the value > > provided at best. > > If it "undermined the value provided at best", then the function would never > have been provided in the first place. It's there for a reason. This is not my opinion - it's a well documented fact. There are a lot of core APIs that are there for the wrong reason - this is one of thousands. SignatureTony Morris http://xdweb.net/~dibblego/ > > I used to hear this term "suggestion" in C++ by people describing how > > "inline" functions work. It's wrong. It's not a suggestion. It's a [quoted text clipped - 4 lines] > toward recycling unused objects in order to make the memory they currently > occupy available for quick reuse." Then the specification used the wrong word. It's a request. It cannot be ignored. It must be addressed. It does not have to be fulfilled, but it *must* be considered. That is simply how the language operates. The function call is made and the code that decides is executed, period. > > > To call gc is general poor form - an attempt to deviate from the already > > > complicated algorithms used by the garbage collector undermines the [quoted text clipped - 6 lines] > > This is not my opinion - it's a well documented fact. Show me. > Then the specification used the wrong word. It's a request. It cannot be > ignored. It must be addressed. It does not have to be fulfilled, but it > *must* be considered. That is simply how the language operates. The > function call is made and the code that decides is executed, period. I don't see that distinction at all. English is a sloppy language, but "suggestion" and "request" in my experience differ only in ways that aren't relevant to a language specification. > > This is not my opinion - it's a well documented fact. > > Show me. It is true that use of System.gc() will never consistently improve the actual performance of your application. The VM uses very sophisticated heuristics to decide when the best times to collect garbage are, and collecting too often means more work per object collected. There are two cases in which System.gc() is useful: 1. Improving the perceived performance of your application. Let's say, for example, that your application involves dealing with very large documents, and you build massive amounts of data structures in the course of working with a document. Since the user knows that documents are very large, the user is likely to be forgiving of an extra second or two of processing time when opening a document. In fact, this is far preferable to a bunch of shorter random delays during the course of working with a document. So when you open a new document and close the old one, you know there will be a lot of garbage around. Now remember you also know that in terms of actual performance, it's best to let the VM decide when to run the garbage collector. However, it's still more acceptable to the user that the collector runs now, causing it to take more time to open a new document, and not that it runs in increments at a later time as you're working with the document. See the distinction? The total time it takes to do work will never be decreased by manually calling the garbage collector; but you can make choices that will be more acceptable to your users from a psychological standpoint. 2. System.gc() is also useful for test programs in programming classes, which demonstrate the behavior of the heap and the garbage collector. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > > Then the specification used the wrong word. It's a request. It cannot be > > ignored. It must be addressed. It does not have to be fulfilled, but it [quoted text clipped - 4 lines] > "suggestion" and "request" in my experience differ only in ways that > aren't relevant to a language specification. It's like the difference between calling a function that *might* call another function, and calling another function yourself directly. > > > This is not my opinion - it's a well documented fact. > > > > Show me. > See the distinction? The total time it takes to do work will never be > decreased by manually calling the garbage collector; but you can make > choices that will be more acceptable to your users from a psychological > standpoint. Of course I see the distinction. I've been on this side of the fence all along. But it's hardly psychological. There's a clear, hard difference there in the way the application operates. > > If you use the same name for the result variable or something like that > > you don't need to worry about memory leaks; The variable is overwritten. > > This is not even close to true. There's some confusion in the use of the words "variable" and "name" in ByteCoder's explanation above. However, if you substitute "variable" for "name", and substitute "value" for "variable", then it starts to become fairly close to the truth. > > If you are about to execute a long and memory intensive task, you might > > do "System.gc();" before (and after) it. That manually starts the > > garbage collection (the process described in the above paragraph), but > > it is not recommended for 'normal' programs, which almost every program > > is. > It doesn't. > It makes a suggestion to run the garbage collector. > This seldom occurs in practice - that is, your suggestion is seldom honoured > by the gc. Whether it's permitted for a VM to ignore System.gc() in the general case is occasionally debated here. I'm of the opinion that it isn't, unless there is no deferred GC work in the algorithm (e.g., ref counting) or there are serious reasons the garbage collector can't do a collection at that time. The API specification specifically calls for a "best effort" to free all unreachable objects, and that doesn't sound much like doing nothing. Under either answer to that question, though, it's patently false to suggest that System.gc() really does, in practice, rarely do anything. Quite the contrary, it almost universally does quite a bit. In pretty much every VM implementation I'm aware of, System.gc() does cause a full stop-the-world garbage collection to occur. > To call gc is general poor form - an attempt to deviate from the already > complicated algorithms used by the garbage collector undermines the value > provided at best. In general, this may be true. However, there are times when a well- placed System.gc() will greatly improve perceived performance. It almost certainly decreases actual performance, but if delays can be concentrated into times when they are expected the result is an application more acceptable to an interactive end-user. I don't know whether that applies to the OP's situation, and neither do you. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > > > If you use the same name for the result variable or something like that > > > you don't need to worry about memory leaks; The variable is overwritten. [quoted text clipped - 24 lines] > "best effort" to free all unreachable objects, and that doesn't sound > much like doing nothing. Where in the API Specification is 'best effort' used? > Under either answer to that question, though, it's patently false to > suggest that System.gc() really does, in practice, rarely do anything. [quoted text clipped - 12 lines] > application more acceptable to an interactive end-user. I don't know > whether that applies to the OP's situation, and neither do you. SignatureTony Morris http://xdweb.net/~dibblego/ > Where in the API Specification is 'best effort' used? From Runtime.gc() (I'm quoting from 1.5, but this sentence has been there for several years.) "When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects." Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >>>Hi, >>> [quoted text clipped - 7 lines] > > This is not even close to true. Ok, I should have used proper jargon. If an Object can't used anymore by any other Object the Garbage Collector will remove it from memory when it runs. >>If you use other names the Java Virtual Machine will decide when Objects >>aren't used anymore and dispose of them when it likes. [quoted text clipped - 13 lines] > complicated algorithms used by the garbage collector undermines the value > provided at best. Like I said, it is very rare that the programmer has a need to call the GC, but if it is called, it *will* execute. How do I know? netBeans has a memory toolbar. If I click on it, it will always run the GC. Signature------------- - ByteCoder - ...I see stupid people ------------- Curiosity *Skilled* the cat > >>>Hi, > >>> [quoted text clipped - 11 lines] > any other Object the Garbage Collector will remove it from memory when > it runs. Quite strange - you suggest that you will use proper jargon, then tell another lie!? http://developer.java.sun.com/developer/Books/performance/performance2/appendixa.pdf Here is some reading for you. > >>If you use other names the Java Virtual Machine will decide when Objects > >>aren't used anymore and dispose of them when it likes. [quoted text clipped - 17 lines] > GC, but if it is called, it *will* execute. How do I know? netBeans has > a memory toolbar. If I click on it, it will always run the GC. Oh that's farly conclusive then - "NetBeans memory toolbar said so" - who can argue with that? Seriously, it's time for you to do some reading. SignatureTony Morris http://xdweb.net/~dibblego/ > Quite strange - you suggest that you will use proper jargon, then tell > another lie!? > http://developer.java.sun.com/developer/Books/performance/performance2/appendixa.pdf > Here is some reading for you. Perhaps it's time for you to explain what problems you are seeing with the statements made here by ByteCoder. I would have phrased it differently -- perhaps something like "If an Object can't be reached in any possible future execution of the application, the Garbage Collector can remove it from memory when it runs." However, I think ByteCoder's explanation reached the essence of the issue. The link you gave goes into a lot of detail on a number of things, sometimes even confusing itself on the difference between specification and implementation, but never justifies why you are being so rude and derogatory toward someone on this newsgroup who's trying to help. > Oh that's farly conclusive then - "NetBeans memory toolbar said so" - who > can argue with that? No one, actually. It turns out that you're assertion that System.gc() doesn't run the garbage collector in practice is just plain wrong, and this is one example of a specific tool that proves it using the most widely used JVM in existence. A counterexample is enough to disprove an assertion. You're really good at sounding confident and being assertive, but please check your facts, or stop being rude to people who correct you. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >>Quite strange - you suggest that you will use proper jargon, then tell >>another lie!? [quoted text clipped - 7 lines] > can remove it from memory when it runs." However, I think ByteCoder's > explanation reached the essence of the issue. [...] Thanks for the support. :) Signature------------- - ByteCoder - ...I see stupid people ------------- Curiosity *Skilled* the cat > > Quite strange - you suggest that you will use proper jargon, then tell > > another lie!? http://developer.java.sun.com/developer/Books/performance/performance2/appendixa.pdf > > Here is some reading for you. > [quoted text clipped - 21 lines] > You're really good at sounding confident and being assertive, but please > check your facts, or stop being rude to people who correct you. I offer no apologies for 'sounding offensive or rude'. If you have misinterpreted my words, so be it, I cannot help you. If I am wrong about something, I have no ego to protect - I expect the same from others. Public forums have people of different cultures, beliefs, etc. I have noticed, when I travel, that certain cultures take a suggestion that 'you are wrong' as some kind of personal attack. You're quite welcome to suggest that I am wrong about something, but I beg of you to leave the emotional stuff at the front door. SignatureTony Morris http://xdweb.net/~dibblego/ > I offer no apologies for 'sounding offensive or rude'. That's a shame. > If I am wrong about something, I have no ego to protect You're being rather egotistical in attacking those who correct you, though. So if you're so impersonal as you claim, why not address an actual issue? Preferably, you'd include information about why you disagree with what others are saying? So far, you've made false statements, and then responded with blanket condemnations to those who try to correct your false statements. For example, I'd like to hear what causes you to think that System.gc() in general doesn't cause the garbage collector to run -- something that you're wrong about. Instead, I can only find you mocking those who are telling the truth about the matter. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > > I offer no apologies for 'sounding offensive or rude'. > [quoted text clipped - 4 lines] > You're being rather egotistical in attacking those who correct you, > though. You think so? Please provide an example. I may have been vague about my answer (is this egotistical?), and I do this typically for one or more of three reasons: 1) It is almost always well documented elsewhere in a way that is far more precise than I can provide (or at least, am prepared to). 2) The request was vague (I will never speculate at the actual intention - red herrings taste bad). 3) I work on the IBM SDK implementation (not at all times, but at the moment, primarily) which means I have knowledge of both Sun and IBM SDK that is not public and cannot be made so. > So if you're so impersonal as you claim, why not address an > actual issue? Preferably, you'd include information about why you [quoted text clipped - 5 lines] > in general doesn't cause the garbage collector to run -- something that > you're wrong about. OK, let's address this one. If you can provide a working example where System.gc() in general, does cause the garbage collector to run, I'll concede, but I'm quietly confident that you cannot (OK, I'm not quiet anymore). I can assure you that what you are observing is far from conclusive, and is specific to your operating environment, VM implementation, etc., etc. A 'closer to the truth' statement might be "System.gc() has run the garbage collector 5 successive times on MyOperatingSystem with MyVMImplementation with MyAmountOfHeapSpace with MyAmountOfCPUBusyState (insert the remaining influencing factors here) and although there is probably no randomness in the MyVMImplementation garbage collector, I cannot be certain that the next 5 times will behave like this for a number of reasons; but for simplicity of an examplanation, I cannot reproduce the exact environment ever again anyway." After you have produced such an example, I will run it in an environment where the garbage collector never runs on a call to System.gc(). Then what will we do? > Instead, I can only find you mocking those who are > telling the truth about the matter. So I was a little sarcastic about a few generalisations (nothing true has been said which has been mocked). My 3 year old does it to me and I do it back. We are both mature enough to 'get over it'. Again, another cultural difference - us aussies 'dungivvafark about chit like that'. When the garbage collector is misunderstood, the most common causes, in my experience, are: - believing that System.gc() will run the garbage collector - this fallacy typically causes problems in debugging a larger memory problem. - reassigning an object reference (typically to null) will cause the object that it referred to to be eligible for garbage collection even if it is the only reference ("If you use the same name for the result variable or something like that you don't need to worry about memory leaks"). The next time that someone 'requests assistance with the garbage collector' and is given a few misdirections, especially those that cause the greatest number of problems on customer sites from my own, perhaps naive observations (I'm only one person - not the best sample set to draw conclusions from), I will correct that person. It is not fair that a request for assistance is responded to with a sole misguidance. I make no apologies for it. SignatureTony Morris http://xdweb.net/~dibblego/ Before this becomes an all-out flamewar, some observations of a previously silent observer: > 1) It is almost always well documented elsewhere in a way that is far > more precise than I can provide (or at least, am prepared to). Then please provide some way to check this information, not just assert it's presence. Not only is that not very helpful, it is what many may percieve as arrogant and insulting behaviour. > 2) The request was vague (I will never speculate at the actual > intention - red herrings taste bad). In this case, it was rather clear, so no points here as well. > 3) I work on the IBM SDK implementation (not at all times, but at the > moment, primarily) which means I have knowledge of both Sun and IBM > SDK that is not public and cannot be made so. And if you can not open the magical box, then bragging about having it won't exactly make you friends either. Or support your argument, for that matter. > OK, let's address this one. > If you can provide a working example where System.gc() in general, > does cause the garbage collector to run, I'll concede, but I'm quietly > confident that you cannot (OK, I'm not quiet anymore). Well, you made the assertion that it generally does not, while the documentation indicates otherwise. So the burden of proof is on your shoulders. Trying to shift it is not only poor form, but in this instance does weaken your position. > I can assure you that what you are observing is far from conclusive, > and is specific to your operating environment, VM implementation, [quoted text clipped - 7 lines] > examplanation, I cannot reproduce the exact environment ever again > anyway." So what? How does this in any way support your view? Maybe it is just me, but you are not making any meaningful attempt at tackling the issue at hand, but rather attempt to obscure the issue by introducing new variables. > After you have produced such an example, I will run it in an > environment where the garbage collector never runs on a call to > System.gc(). Then what will we do? Well, so what again? It is the general case (and not in the mathematical sense, but in the sense of "generally occuring") we are examining here. > > Instead, I can only find you mocking those who are > > telling the truth about the matter. [quoted text clipped - 5 lines] > Again, another cultural difference - us aussies 'dungivvafark about > chit like that'. I am afraid this has nothing to do with culture. Certain standards of behaviour are pretty universal in the so-called "western hemisphere" > The next time that someone 'requests assistance with the garbage > collector' and is given a few misdirections, especially those that [quoted text clipped - 3 lines] > fair that a request for assistance is responded to with a sole > misguidance. I make no apologies for it. I am afraid the one who has so far offered nothing but half-correct and unfounded assertions. Certainly carried with a lot of panache, but still nothing that would make them any more valid then the others offered. Rather less, since other posters have been willing and able to provide indications that their views are in fact correct. So without needlessly stepping on your toes: Either take that ego down a few notches, or put your cards on the table for all to see. And that is all i am going to write on this topic See you Stefan SignatureIn pioneer days they used oxen for heavy pulling, and when one ox couldn't budge a log, they didn't try to grow a larger ox. We shouldn't be trying for bigger computers, but for more systems of computers. --- Rear Admiral Grace Murray Hopper > Before this becomes an all-out flamewar, some observations of a > previously silent observer: [quoted text clipped - 5 lines] > it's presence. Not only is that not very helpful, it is what many may > percieve as arrogant and insulting behaviour. I did that earlier. > > 2) The request was vague (I will never speculate at the actual > > intention - red herrings taste bad). > > In this case, it was rather clear, so no points here as well. Agreed. > > 3) I work on the IBM SDK implementation (not at all times, but at the > > moment, primarily) which means I have knowledge of both Sun and IBM [quoted text clipped - 3 lines] > won't exactly make you friends either. Or support your argument, for > that matter. I haven't bragged about anything; only offered a reason why I don't offer a reason. It supports my reason for not offering a reason which was the intention. Why are these preconceptions added? > > OK, let's address this one. > > If you can provide a working example where System.gc() in general, [quoted text clipped - 5 lines] > shoulders. Trying to shift it is not only poor form, but in this > instance does weaken your position. Which documentation are you referring to? No documentation has been provided other than 'best effort' in java.lang.Runtime. This is ambiguous at best. > > I can assure you that what you are observing is far from conclusive, > > and is specific to your operating environment, VM implementation, [quoted text clipped - 12 lines] > at hand, but rather attempt to obscure the issue by introducing new > variables. Would you like me to post the SDK source code? > > After you have produced such an example, I will run it in an > > environment where the garbage collector never runs on a call to > > System.gc(). Then what will we do? > > Well, so what again? It is the general case (and not in the mathematical > sense, but in the sense of "generally occuring") we are examining here. I wasn't clear on that until now. > > > Instead, I can only find you mocking those who are > > > telling the truth about the matter. [quoted text clipped - 8 lines] > I am afraid this has nothing to do with culture. Certain standards of > behaviour are pretty universal in the so-called "western hemisphere" If I said some of the things I say here when I visit the US or UK, I would offend every person I spoke to (less so in the UK). There is a huge cultural difference, between the US, UK, and Australia. I agree it often goes unnoticed. > > The next time that someone 'requests assistance with the garbage > > collector' and is given a few misdirections, especially those that [quoted text clipped - 16 lines] > See you > Stefan I'm over it anyway. This argument won't turn into a flame war because I tend not to enter them. That is, as constructive argument tends towards zero, I make the judgement call to cease responding. Chris probably will at some stage too. SignatureTony Morris http://xdweb.net/~dibblego/ > > And if you can not open the magical box, then bragging about having > > it won't exactly make you friends either. Or support your argument, [quoted text clipped - 4 lines] > It supports my reason for not offering a reason which was the > intention. Why are these preconceptions added? As i said, if you can't open the box, it is best not to mention it at all. And if you need to mention the box to make some claim... > > Well, you made the assertion that it generally does not, while the > > documentation indicates otherwise. So the burden of proof is on your [quoted text clipped - 5 lines] > java.lang.Runtime. > This is ambiguous at best. This is (AFAIK) intentionally left vague, yes. But best effort tends to be decidedly greater then "no effort at all" on pretty much any platform (some special cases may differ in one way or the other) > > So what? How does this in any way support your view? Maybe it is > > just me, but you are not making any meaningful attempt at tackling > > the issue at hand, but rather attempt to obscure the issue by > > introducing new variables. > > Would you like me to post the SDK source code? Yes! (Though i really doubt you will) ;) > I'm over it anyway. > This argument won't turn into a flame war because I tend not to enter > them. That is, as constructive argument tends towards zero, I make the > judgement call to cease responding. > Chris probably will at some stage too. Well, the critical point from which it could be called such has been overstepped IMHO, but that's my view on it. Yes, i have broken my resolution of posting only one reply to this topic. Sue me! ;) SignatureIn pioneer days they used oxen for heavy pulling, and when one ox couldn't budge a log, they didn't try to grow a larger ox. We shouldn't be trying for bigger computers, but for more systems of computers. --- Rear Admiral Grace Murray Hopper > > I'm over it anyway. > > This argument won't turn into a flame war because I tend not to enter [quoted text clipped - 4 lines] > Well, the critical point from which it could be called such has been > overstepped IMHO, but that's my view on it. Shall we all go to the pub then? :) SignatureTony Morris http://xdweb.net/~dibblego/ [Most of this conversation snipped.] > Which documentation are you referring to? > No documentation has been provided other than 'best effort' in > java.lang.Runtime. > This is ambiguous at best. It's definitely true that "best effort" is ambiguous. However, it would take some mighty linguistic gymnastics to turn "best effort" into "no effort at all" when deferred garbage collection work exists that can be started at any time. Of course, if a garbage collection cycle has just completed, or if you're working on some weird VM where there is never deferred garbage collection work (such as a pure ref-counting VM), then "best effort" might indeed indicate no effort. There are other cases as well; locking policy may prevent garbage collection while the finalizer thread is busy, or some other implementation-specific barrier may exist to prevent the collector from running. That's why the spec can't guarantee that a call to System.gc() will cause the collector to run. Outside of those corner cases, however, a "best effort" would at least seem to indicate that if there's applicable code in the virtual machine to run garbage collection, that it should be run. I'd argue that "best effort" means even more than that; for example, that a full garbage collection should be run instead of just a quick younger-generation collection, if the collector is generational. The blurry lines start appearing, though, when you start asking for things like this. For example, if the only entry point to the GC module of a VM is for a generational collection -- and complete collections only occur when intermediate or old generations become full -- then an unconditional full collection may not be required by the phrase "best effort"... or it may, depending on interpretation (in the latter of which, the above-mentioned hypothetical GC module would have to be modified before the VM could comply with the API spec). Back on the question of whether collection generally gets run, though, there's an easy way to experiment with this. Run the VM (at least the Sun VM) with the -verbose:gc option, with an application that regularly calls System.gc at even time intervals. You'll see a collection happening every time. Whether or not a garbage collection is required (as I think it is except in unusual cases), it really does happen. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > So I was a little sarcastic about a few generalisations (nothing true has > been said which has been mocked). > My 3 year old does it to me and I do it back. Ah, I'm starting to get it now. > Hi, > > Is it possible to remove a specific object (instantiated) whilst the > running a program. I'm writing a highly repeatative task and dont want > to suck the systems memory having old information stored in the memory. > Thanks for any help, Jon All of the other posts have provided a good description of the GC in java, so I won't add anything to it. However, a suggestion that often helps for this sinerio is to treat Java like any other language, when performance is an issue. So.... 1) Is there actually a performance problem? Write the code, then test it with a profiler to see if it is not the best performance. If and only if you know the code is badly performing (because of some testing) then attempt some/ all of the following: 2) Don't create objects if necessary, its 'generally' quicker to reuse an existing object than to create new ones. 3) Ensure objects are de-referenced as soon as possible, to allow the GC to remove as many objects as possible, as soon as possible. 4) Employ the relevant patterns that aid memory consumption - flyweight, etc.. 5) Look for silly yet problematic issues like - new-ing Boolean objects, instead of using Boolean.valueof(boolean b); http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Boolean.html#valueOf(boolean) 6) ....for others to fit in. Failing all of that, post your code and its unit test code if available, and we can all have a go at optimizing it for you. HTH Andrew I have seen a demo regarding the finalize method that seems to answer your question. It seems that calling the garbage collector method is not enough, you would need to mark your object by assigning a null value to the object reference and then calling System.gc(); Hope that helps. > Hi, > > Is it possible to remove a specific object (instantiated) whilst the > running a program. I'm writing a highly repeatative task and dont want > to suck the systems memory having old information stored in the memory. > Thanks for any help, Jon Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.