0

In a Java program which I did not made and cannot change, only write extensions for it, the design forces me to create an object which will never be garbage collected. I tested and I can do it through the use of statics or anonymous object instantiation. I know I can do something like:

public static MyObject eternalObject = new MyObject();

and have it accessible anytime I want on other parts of the program. But I can also make something like: 

methodOfBadDesignedProgramWhichIDidNotCreate(new MyObject());

and the program will have the object available to use it.

I have analyzed the heap dump, and in both cases the object never gets garbage collected and lives until the end of the program. The program has a terrible design since it forces you to use a lot of statics for the creation of extensions. Not to mention that most of its methods are statics and has over 2000 static variables.

I've been trying to mitigate memory leaks on it and was wondering if one usage has any advantage over another. Note that contrary to popular belief, in this specific case, anonymous object instantiation does not die at the end of the method execution because the program is so badly designed that the reference is never lost. Even when the object is not in use.

So for an object that is never garbage collected by design, does anonymous object instantiation offer advantages over a static object creation?

P.S. I would understand if this question gets closed for being too localized as it is obvious this is very bad programming design that only a small amount of population would have to deal with so they would not care about it, but I have to deal with this bad design because my boss forces me to do so and doesn't allow me to create a new program from scratch, only create extensions for it. I am just trying to mitigate the memory leaks and do the best quality programming I can on the job. Therefore, I ask. To understand if one use has advantages over another and leave either educated or convinced that there is nothing I can do about this bad designed piece of software for which I cannot change the code or create a new one.

user5950
  • 113
  • 2
  • Even 2k static objects don't cost that much of RAM, there is no need for you to pass time about that. The very problem would be : are those objects use concurrently and are they thread safe ? – Walfrat Apr 18 '17 at 07:43
  • I understand. Thanks. Yes, they are used concurrently, but they are thread safe. Edit: My observations on the memory behavior show me the variables being accessed from different threads, sometimes 50 threads, and everything is fine. – user5950 Apr 18 '17 at 07:45
  • And the leaks, leaks are problematic when it's connections, files, and everything related to IO, and threads leak, what about those ? If you use Java, Sonar can track it for you. – Walfrat Apr 18 '17 at 07:46
  • I was tracking the leaks with VisualVM. I was able to hunt down some and fix them. I will check with Sonar then. I did not found leaks related to IO or threads, but I did found leaks on objects creation that retained memory. But I fixed those already. Thanks. – user5950 Apr 18 '17 at 07:54
  • 1
    Can you **please** remove the rant parts, the excuses and the repetition of "I can only write extensions for it" from the question? This reads horrible and distracts from your main question. – Doc Brown Apr 18 '17 at 09:33
  • Yes. No problem. I removed some. I don't feel I was ranting thought. I just felt the necessity of making it clear that it was not my code and therefore I could not modify the design. Only design my own extension for it and adapt it to the requirements of the original program. But it's okay. I removed some parts of it. :) – user5950 May 08 '17 at 11:58

2 Answers2

1

So for an object that is never garbage collected by design, does anonymous object instantiation offer advantages over a static object creation?

I believe you are referring to the following as "static object creation?"

public static MyObject eternalObject = new MyObject();

The thing is that from the Java perspective, an above such object is created at class initialization time, but that is runtime. There really is no such thing as static object creation: all objects are instantiated at runtime. While fields can be declared static and hence statically allocated/created, objects cannot. A static field initializer is executed at runtime (albeit during class loading) very much like other statements.

Thus, from the GC point of view of the language, this object instantiation is the same as any other object instantiation.

(Various low level storage analysis optimizations not withstanding, but optimization could apply to a wide variety of forms including the other you suggest).

Erik Eidt
  • 33,282
  • 5
  • 57
  • 91
  • A nitpick, albeit irrelevant to this question: *There really is no such thing as static object creation: all objects are instantiated at runtime* ... except string constants, which are simply assumed by the byecode to already exist by the time the class is loaded. There are at least some JVMs that preallocate them in compiled modules (which may be cached between executions) ... I know this because many years ago I wrote one. – Jules Apr 18 '17 at 20:32
  • I am terribly sorry for the late reply. I had no internet access for a good while. Thank you for your answer. I was referring that the object is static. Not really about object creation. I chose a bad wording to describe what I meant. Sorry about that. I should have said: "...advantages over the usage of a static object?..." To refer to the question regarding advantages of using an anonymous object over a static one if any in this specific situation. Once again, thanks for your explanation. It DOES answers what I asked with the wrong wording even though it is not what I meant to ask. Thanks. – user5950 May 08 '17 at 11:49
  • @user5950, no problem. To be clear and reiterate, there is no such thing in Java as a *static object*; it has only a notion of a *static field*, which, at best, can be a reference to an allocated object. – Erik Eidt May 08 '17 at 16:14
  • Understood. I used again the word "static object" in that comment I made. I keep making the same mistake on my wording. But I understand the concept you mean. I'll keep repeating myself what you said to not make the same wording mistake in the future when writing. Thank you. – user5950 May 10 '17 at 06:44
0

My guess about what happens in methodOfProgramWhichIDidNotCreate is something like 

  void methodOfProgramWhichIDidNotCreate(MyObject m)
  {
      staticMember = m;
  }

where staticMember is a private static member variable, just like your variable eternalObject. If my guess is correct, the answer is simply "no", since both ways to store your object are essentially the same from the garbage collector's point of view.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565