Regarding memory Allocation

[srinivas pichuka]

When you have a method that always return the same object from the session using the getter method of session.
Example: public Long getSession()
               {
                  return session.getObject("key");
               }


You want the same method to be called multiple times in the code. Is it fine to first call the method once and hold the result in a variable at the starting of the code, and later reuse it (or) call the method multiple times ?  

To me calling the method multiple times would be a good thing, because, that method is not doing anything, except that, it returns the same object from the session by calling the getter of the session.
But on the other hand, if you declare a variable to hold the object, and reuse the variable everywhere, thoughout the code, it may be a bit expensive as declaring a variable itself will allocate certain space in the memory, which I think is un-necessary.  

Could anybody suggest on this...and also how to test this...?  I tried with Runtime.getRuntime().freeMemory(), but it always return me the same value.

[Campbell Ritchie]

Welcome to the Ranch

I was a bit confused about your thread title, because you are not asking about allocating memory at all.
Are you absolutely sure you will never have a change in the object to be returned? Are you sure you can safely return it? If it is a mutable reference type, you cannot safely return it at all. Not without taking a copy. You do not need a defensive copy for an immutable class, nor for a primitive.

public final class MyImmutableClass
{
   private int hashCode;
   private final int i;
   private final String s;
   private final List<SomethingImmutable> list;
   /*
    * Can we be sure the List will never change its state?
    */

   public MyImmutableClass(int i, String s, List<SomethingImmutable> list)
   {
      if (s == null || list == null)
      {
          throw new NullPointerException("nulls not permitted in this constructot.");
      }
      this.i = i;
      this.s = s;
      this.list = Collections.unmodifiableList(new ArrayList<>(list));
   }

/*
 * getXXX methods, toString and equals
 */

   @Override
   public int hashCode()
   {
      if (hashCode == 0)
      {
         hashCode = Object.hash(i, s, list);
      }
      return hashCode;
   }
}

Now, I think I have got a truly immutable class here; once it has been instantiated, its state cannot change. If its state cannot change, then its hash code won't change either. So if the hash code is ever required, I have arranged for it to be cached as a field. If any of the fields change their state, that would be a disastrous arrangement. I think that is all right. Two challenges for you:-

1: Change it so the hash code is evaluated eagerly rather than lazily.

2: If my hash code cannot change and can safely be cached, why cannot your object be cached and returned safely?

I would think it would be all right, but you must be absolutely sure your object cannot change its state.

But it is as fast to retrieve a “V” from a Map, so is this more effort than is necessary?

[Junilu Lacar]

1. DON'T worry about memory usage UNLESS you can objectively show that there is a problem, usually by using a profiler. Programmers are notoriously horrible at judging performance issues and similar things using their gut feelings/intuition. Don't do it.  
2. Let the JVM worry about allocating/deallocating memory. That's what the Garbage Collection is there for.
3. DO worry about code clarity and cohesion, loose coupling, and testability.
4. DO favor making the scope and lifetime of variables to be as small/short as possible.

[srinivas pichuka]

@Campbell Ritchie: Thank You it's a good information.  But actually, I think I did not communicate my question correctly. Anyway, I will try to explain it one more time by an example.


1st Scenario: (getting the value, by calling the method each time).

public class Test1 
{
   public Long getId()
  {
     return 2L;
   }

  public static void main(String[] args)
{
   Test1 t1 = new Test1();
   System.out.println(t1.getId());
   System.out.println("Again printing getId: +t1.getId());
   System.out.println("Lastly getting the getId: +t1.getId());
}
}

2nd Scenario: (assign the getId() to the variable and use the variable throught the program)

public class Test1 
{
   public Long getId()
  {
     return 2L;
   }

  public static void main(String[] args)
{
   Test1 t1 = new Test1();
   Long t = getId();
   System.out.println(t);
   System.out.println("Again printing getId: +t);
   System.out.println("Lastly getting the getId: +t);
}
}

My Question: Is calling multiple times (as in 1st scenario), occupies more space   (or) the as in the second scenario (assign it to variable). Which one is much efficient  in terms of space ? I believe that the second option is not good, because unnecessarily the variable t, will get some space allocated.
Please let me know your thoughts on this.

[Campbell Ritchie]

I added code tags to your post; always use them because you can see how much better it looks
What you have shown is different from what you asked at first. You are always returning the same value as an ID, which is probably wrong. You are also using a Long: why?

Why on earth are you worrying about such a small amount of memory? The amount of effort even asking that question is more than the memory consumption is worth. Anyway: you have local variables. I suggest you work out where local variables live and how much difference they will make to memory allocation. You might do well to print the bytecode for those two bits of code with the javap tool.

[Dave Tolls]

This really is one of those things where you should be concentrating on what is more readable rather than any (minute at best) memory or performance savings.