• (cs) in reply to Jean-Marc
    Jean-Marc:
    Java doesn't reference count... but I get what you are saying.
    *facepalm* *headdesk* *selfasskick* Well durrr me. You would have thought I should have known that, given that I just spent a week rewriting the internals of the boehm GC in order to support libgcj on Cygwin...

    In my defence, at least I "get" the notion of passing references by value well enough to realise that it would necessitate incrementing the reference count when instantiating the functions formal parameters... if only there had actually been one, LOL!

  • Thygrrr (unregistered) in reply to diodor
    diodor:
    frits:
    You know nulling objects to "help" the garbage collector is usually considered bad practice, right?
    But in J2ME is IMPERATIVE to do it or you'll run out of memory quickly.... So I'll have to read more before believe it (Im going to google it now)

    Sorry, but that's a myth (bullshit, actually, and still very popular among JavaME coders :))!

    The only case where it makes actual sense to do this is when you overwrite a reference with one to a new object, and both objects are sufficiently huge (e.g., large images) so you can expect the garbage collector to run during the second instantiation because there is not enough free memory left for the 2nd object.

    In fact, you can generalize this as "discard your references to objects you don't need anymore before you instantiate new ones that might not fit into memory". Most modern JavaME phones have plenty of heap space, so it's only really relevant when it comes to images or audio.

    HugeImage myImage = new HugeImage();
    //... later ...
    myImage = null;
    myImage = new HugeImage();
    
  • Tuna (unregistered) in reply to Dan
    Dan:
    <Java> uses mark and sweep.

    No, it doesn't. It uses a generational collector where the young generation is collected by copying.

    Thank you for playing.

  • (cs) in reply to Tuna
    Tuna:
    Dan:
    <Java> uses mark and sweep.

    No, it doesn't. It uses a generational collector where the young generation is collected by copying.

    Thank you for playing.

    No, thank you for playing, since apparently you believe there is only one JVM in the world?

    I can tell you for an absolute fact that the GCJ/libjava JVM uses the Boehm GC to do mark and sweep.

  • Bob (unregistered) in reply to Medinoc

    Don't encourage foolishness. Setting things to null is a huge mistake in Java programming in all but a very small number of cases. The best case is you wind up with something set to null which should have been set to something which gave a more useful error when it was called erroneously later.

  • methinks (unregistered) in reply to Thygrrr
    Thygrrr:
    diodor:
    frits:
    You know nulling objects to "help" the garbage collector is usually considered bad practice, right?
    But in J2ME is IMPERATIVE to do it or you'll run out of memory quickly.... So I'll have to read more before believe it (Im going to google it now)

    Sorry, but that's a myth (bullshit, actually, and still very popular among JavaME coders :))!

    The only case where it makes actual sense to do this is when you overwrite a reference with one to a new object, and both objects are sufficiently huge (e.g., large images) so you can expect the garbage collector to run during the second instantiation because there is not enough free memory left for the 2nd object.

    In fact, you can generalize this as "discard your references to objects you don't need anymore before you instantiate new ones that might not fit into memory". Most modern JavaME phones have plenty of heap space, so it's only really relevant when it comes to images or audio.

    HugeImage myImage = new HugeImage();
    //... later ...
    myImage = null;
    myImage = new HugeImage();
    

    Sorry, but this is complete hogwash - nulling a reference and overwriting it with a new reference has the exact same effect - the reference is lost either way, and this renders the object eligible for garbage collection if there are no more references to it in the so-called "root set of references".

    It is not guaranteed anyway that the first object is collected prior to the instantiation of the second one, no matter whether you overwrite its reference with null or directly with the new one.

    OTOH the VM will run the gc in any case if there should not be enough space for the second object (thus collecting the first one), again no matter if you overwrote the first reference with null or with the new reference.

  • CloneNotSupportedException (unregistered) in reply to frits
    frits:
    I know java:
    nobody:
    agreed.

    you guys call yourselves coders? rule 1. stfu if you don't know and don't try to pull it out of your ass. rule 2. it's not pass by value. go to rule 1.

    Hmmm, pass by reference, pass by value. In Java there are two kinds of type: primitive types and reference types. There are, therefore two kinds of value: primitive values and reference values. Calls to methods are by value, the arguments being either primitive values or reference values.

    If you are unclear on this take a look at the JLS Edition 3, section 4.1 (http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html). If you can't understand what it says there then please fuck off.

    Don't persist myths like Java is pass by reference. It's misunderstandings like that that lead to code of the calibre shown in the original post.

    If you think Java is pass by reference then could you write a simple swap function?

    //Assumption a[] and b[] have one element each
    void swap(Object a[], Object b[])
    {
       object temp = a[0].clone();
       a[0] = b[0].clone();
       b[0] = temp;
        
    }
    

    A swap function that works would be even better. This will not compile. I think there may be a typo, but even then, assuming it should be Object temp = ... , clone is protected. Digging a bit further still, clone may throw CloneNotSupportedException.

    I'm not sure that you would need the clone for what you are trying to do, but, regardless of that, it's not a simple swap function. Perhaps you could explain how your code should be used and what makes it simpler than simply writing the swap inline.

    In any case creation of a simple swap function in Java seems to have been less than simple.

  • DH (unregistered) in reply to _sam

    I have to echo what some other users have said here:

    I feel much more knowledgable about Java after reading some of the woefully-off-target stabs in the dark being made by C programmers.

    As-written, is it pointless code? Yes.

    But some folks are trying a bit too hard to find more than that.

  • Java Geek (unregistered) in reply to methinks
    methinks:
    Thygrrr:
    diodor:
    frits:
    You know nulling objects to "help" the garbage collector is usually considered bad practice, right?
    But in J2ME is IMPERATIVE to do it or you'll run out of memory quickly.... So I'll have to read more before believe it (Im going to google it now)

    Sorry, but that's a myth (bullshit, actually, and still very popular among JavaME coders :))!

    The only case where it makes actual sense to do this is when you overwrite a reference with one to a new object, and both objects are sufficiently huge (e.g., large images) so you can expect the garbage collector to run during the second instantiation because there is not enough free memory left for the 2nd object.

    In fact, you can generalize this as "discard your references to objects you don't need anymore before you instantiate new ones that might not fit into memory". Most modern JavaME phones have plenty of heap space, so it's only really relevant when it comes to images or audio.

    HugeImage myImage = new HugeImage();
    //... later ...
    myImage = null;
    myImage = new HugeImage();
    

    Sorry, but this is complete hogwash - nulling a reference and overwriting it with a new reference has the exact same effect - the reference is lost either way, and this renders the object eligible for garbage collection if there are no more references to it in the so-called "root set of references".

    It is not guaranteed anyway that the first object is collected prior to the instantiation of the second one, no matter whether you overwrite its reference with null or directly with the new one.

    OTOH the VM will run the gc in any case if there should not be enough space for the second object (thus collecting the first one), again no matter if you overwrote the first reference with null or with the new reference.

    It has not the same effect.

    Try this with: -Xms24M -Xmx26M

    public class GCTest 
    {
    
    	public static void main(String[] args) 
    	{
    		int [] trash;
    		
    		trash = new int[4 * 1024 * 1024];
    		//trash = null;
    		trash = new int[4 * 1024 * 1024];
    	}
    
    }
    

    If you do not null the reference, you will get a 'java.lang.OutOfMemoryError: Java heap space' exception. That is because the JVM allocates memory first and then replace the reference.

    Captcha: esse, ich esse gerade nichts obwohl mein Magen knurrt !

  • asdf (unregistered) in reply to Alastriona

    Why the fuck did you first post something completely wrong and only after that actually find out the stuff you are talking about?

  • jverd (unregistered) in reply to Tuna
    Tuna:
    Dan:
    <Java> uses mark and sweep.

    No, it doesn't. It uses a generational collector where the young generation is collected by copying.

    Thank you for playing.

    Don't the older generations use M&S though?

  • (cs)

    This is exactly the kind of sh*t you get when you insist to say that Java has call-by-reference semantics, while in fact it's strictly call-by-value in a local JVM.

    There is subtle but important difference between passing a pointer by value (what Java does) or passing a variable by reference (which Java doesn't).

  • Squid (unregistered) in reply to Lunkwill

    I hate java. My teacher used to say stupid stuff as examples and give us some code to copy, then piss off out the class until it was 3 mins from ending. By which time only one person in the class had managed to get it to work and he'd used a totally different method (some smug guy that already knew how to code).

    I could never be assed to get a book as the language just seems retarded and why do people feel the need for such long variable names?

  • Wowzers (unregistered)

    TRWTF here is the astounding amount of ignorance in the comments. I estimate that over 9 of 10 comments contain misleading, misguided or just plain incorrect information.

    Even better are the ones that take on a condescending tone after stating something completely incorrect as fact.

    Seriously, if you're not 100% sure about what you're going to say, keep your mouth shut. Especially if you're going to open it to rag on some other ignorant mutt.

  • Brian (unregistered) in reply to Dave

    This will at least throw compiler warning, but it is probably asking too much for someone to read those.

  • Carl (unregistered) in reply to Steve W

    Sorry you are wrong, the method call is static so it will not create a new Destruction object every time, the second part of your answer is correct ;-)

  • withheld (unregistered) in reply to cconroy

    s/(Irish)/dancing \1/

Leave a comment on “Java Destruction”

Log In or post as a guest

Replying to comment #:

« Return to Article