Develop Reference

Instance created inside of a Method

I have not been able to find any reliable literature on this but i'm curious as to where an object is stored if its created inside of a method ? on the stack or on the heap in java 8?
public class A {}
.
.
.
public class B {
public void test(){
A m = new A();
}
}
I know that normally only local primitives, reference variables and function calls are stored on the stack and that objects are stored in the heap
So I'm assuming that one of the following two scenarios is true either
Case 1 : Objects instantiated in a method are as usual stored in the heap with a reference to that object in the stack then when the function finishes the object reference goes out of scope and the object in the heap is then available for garbage collection
Case 2 : Objects instantiated in a method are stored in the stack then are available for garbage collection when function finishes
I strongly suspect its case 1, it wouldn't make sense to store an object in a stack, the only reason I have doubts is because ive come across some literature saying on the stack and others on the heap
Thanks for your feedback ahead of time

The local reference variable is on the stack, and the object is in the heap.
Note that your question title,
Instance declared inside of a Method
is misleading since objects/instances are declared nowhere -- only variables are, and the object created in a method can be placed on fields into a collection, or anywhere it's needed. And so there is no guarantee that the object should be GC'd when the method exits.

All the objects are stored in the heap ... the garbage collector runs whenever there's a lack of memory so it get rid of the objects that are not used anymore and there's no reference to them too.

Your assumption specified in Case 1 is correct. Here is a good source on memory allocation in java.
Java Heap Space vs Stack – Memory Allocation in Java

If they are not immediate "values" (not like an int property in a class object), only their reference values are stored in the stack. their actual values and structures are stored in the heap.
these are stored in the stack as they are;
int i=10;
float f=10.00;
bool b=true;
these will have only references on the stack, they will reside in the heap (any kind of class variable is part of the structure and be created on the heap altogether);
int[] ii={1,2,3};
double[] dd = new double[10];
String s="String!!";
Object o=new Object();
when passed to a method, Values are copied to a new stack variable (unless converted to a reference object). References are also passed to a copycat stack variable, but since they are references, both will redirect to the same object (unless copied to a whole new object manually).
this part might not be of interest in the topic, you decide
In the following code, number is created on the stack and copied to a new stack value for the method, hello created on the heap, passed by reference to s then two strings concatenated on another heap address and it now holds this new address (strings are immutable). The Point object is not immutable as strings, so it can be changed anywhere you referenced it as they are created on the heap to access freely.
class Point{ int x;int y; Point(int x,int y){this.x=x;this.y=y;} }
public class TestClass{
public static void main(String []args){
int number=5;
String hello="Hello";
Point point = new Point(2,4);
Print(number,hello,point);
System.out.println(hello+" "+number+" "+point.x+" "+point.y);
}
public static void Print(int i,String s,Point p){
i+=5;
s+="World!";
p.x+=2; p.y+=2;
System.out.println(s+" "+i+" "+p.x+" "+p.y);
}
}

Why does a non-static field not act as a GC root?

As I know static fields (along with Threads, local variables and method arguments, JNI references) act as GC roots.
I cannot provide a link that would confirm this, but I have read a lot of articles on it.
Why can't a non-static field act as a GC root?

First off, we need to be sure we're on the same page as to what a tracing garbage collection algorithm does in its mark phase.
At any given moment, a tracing GC has a number of objects that are known to be alive, in the sense that they are reachable by the running program as it stands right now. The main step of mark phrase involves following the non-static fields of those objects to find more objects, and those new objects will now also be known to be alive. This step is repeated recursively until no new alive objects are found by traversing the existing live objects. All objects in memory not proved live are considered dead. (The GC then moves to the next phase, which is called the sweep phase. We don't care about that phase for this answer.)
Now this alone is not enough to execute the algorithm. In the beginning, the algorithm has no objects that it knows to be alive, so it can't start following anyone's non-static fields. We need to specify a set of objects that are considered known to be alive from the start. We choose those objects axiomatically, in the sense that they don't come from a previous step of the algorithm -- they come from outside. Specifically, they come from the semantics of the language. Those objects are called roots.
In a language like Java, there are two sets of objects that are definite GC roots. Anything that is accessible by a local variable that's still in scope is obviously reachable (within its method, which still hasn't returned), therefore it's alive, therefore it's a root. Anything that is accessible through a static field of a class is also obviously reachable (from anywhere), therefore it's alive, therefore it's a root.
But if non-static fields were considered roots as well, what would happen?
Say you instantiate an ArrayList<E>. Inside, that object has a non-static field that points to an Object[] (the backing array that represents the storage of the list). At some point, a GC cycle starts. In the mark phase, the Object[] is marked as alive because it is pointed to by the ArrayList<E> private non-static field. The ArrayList<E> is not pointed to by anything, so it fails to be considered alive. Thus, in this cycle, the ArrayList<E> is destroyed while the backing Object[] survives. Of course, at the next cycle, the Object[] also dies, because it is not reachable by any root. But why do this in two cycles? If the ArrayList<E> was dead in the first cycle and if Object[] is used only by a dead object, shouldn't the Object[] also be considered dead in the same move, to save time and space?
That's the point here. If we want to be maximally efficient (in the context of a tracing GC), we need to get rid of as many dead objects as possible in a single GC.
To do that, a non-static field should keep an object alive only if the enclosing object (the object that contains the field) has been proved to be alive. By contrast, roots are objects we call alive axiomatically (without proof) in order to kick-start the algorithm's marking phase. It is in our best interest to limit the latter category to the bare minimum that doesn't break the running program.
For example, say you have this code:
class Foo {
Bar bar = new Bar();
public static void main(String[] args) {
Foo foo = new Foo();
System.gc();
}
public void test() {
Integer a = 1;
bar.counter++; //access to the non-static field
}
}
class Bar {
int counter = 0;
}
When the garbage collection starts, we get one root that's the local variable Foo foo. That's it, that's our only root.
We follow the root to find the instance of Foo, which is marked as alive and then we attempt to find its non-static fields. We find one of them, the Bar bar field.
We follow the fields to find the instance of Bar, which is marked as alive and then we attempt to find its non-static fields. We find that it contains no more fields that are reference types, so the GC doesn't need to bother for that object anymore.
Since we can't get find new alive objects in this round of recursion, the mark phase can end.
Alternatively:
class Foo {
Bar bar = new Bar();
public static void main(String[] args) {
Foo foo = new Foo();
foo.test();
}
public void test() {
Integer a = 1;
bar.counter++; //access to the non-static field
System.gc();
}
}
class Bar {
int counter = 0;
}
When the garbage collection starts, the local variable Integer a is a root and the Foo this reference (the implicit reference that all non-static methods get) is also a root. The local variable Foo foo from main is also a root because main hasn't gone out of scope yet.
We follow the root to find the instance of Integer and instance of Foo (we find one of these objects twice, but this doesn't matter for the algorithm), which are marked as alive and then we attempt to follow their non-static fields. Let's say the instance of Integer has no more fields to class instances. The instance of Foo gives us one Bar field.
We follow the field to find the instance of Bar, which is marked as alive and then we attempt to find its non-static fields. We find that it contains no more fields that are reference types, so the GC doesn't need to bother for that object anymore.
Since we can't get find new alive objects in this round of recursion, the mark phase can end.

A non static field has a reference held by the instance that contains it, so it cannot be a GC root on its own right.

Comparator as an anonymous sorter in a stream

Let's say I am trying to sort a collection with a specific Comparator. Does it matter from a performance point of view to have a comparator defined in the sorted() clause of as a an anonumous instance, or it is better to create an instance once and just call compare method in the sorted() clause?
In essence, what is better:
myCollection.stream().sorted(
new Comparator<String>(){
public int compare(String a, String b){
//code
}
})
Comparator<String> comp = new MyCustomComparator<>();
myCollection.stream().sorted(comp::compare)
Note: neither syntax, nor comparing values matter - I want to know conceptually whether JVM is smart enough to initialize my anonymous comparator only once (case 1) and keep reusing just one method, or it will keep creating new instances (then I would choose case 2)

A new instance of an anonymous class will be created every time the expression using new is evaluated.
In your first example, a new one is created every time the statement runs where you are passing it to sorted.
In your second example, a new one is created wherever the comp variable is being initialized. If comp is an instance member, then it gets created whenever the object that owns it is created. If comp is a local variable in a method, then it gets created every time the method is called.
A static, stateless and non-capturing Comparator is always going to be the most efficient way, because you can create it once and keep it forever. (See for example String.CASE_INSENSITIVE_ORDER.)
That's not to say you shouldn't use another way.
In Java 8, you should prefer lambdas over anonymous classes. Non-capturing lambdas can be cached and only created once. For example, this program outputs true:
class Example {
public static void main(String[] args) {
System.out.println(comparator() == comparator());
}
static Comparator<String> comparator() {
return (lhs, rhs) -> lhs.compareTo(rhs);
}
}
(Example on Ideone.)
All that said, you shouldn't worry about creating a few small objects here in there in Java, because it's unavoidable and the garbage collector is optimized for it. The vast majority of the time, the "best" way to do something is also the most readable.
Note that you do not have to use a method reference in your second example. You can pass it to the method directly:
Comparator<String> comp = new MyCustomComparator<>();
myCollection.stream().sorted(comp)...

Runtime for both approach will be the same. This can be expressed as below :
For 1st scenario, first JVM create instance of comparator with your custom code for compare method and allocated space for this object anonymously. So ultimately object is created and allocated memory without some pointing reference for user and once function call is over object is registered for GC.
For 2nd scenario, JVM again created new instance of comparator with custom code and allocated space and also provide reference stored in separate variable so that this object can be used again but here object won't be collected by GC if same is used again in code anywhere else. So when GC runs for next time, it has to scan for references of variable and figure out whether it can be GCed or not.

Does Java allocate memory for class' fields even if they are not initialised yet?

I'm trying to perform a small memory optimisation for my Java game. It is a bit unclear to me how does Java allocate memory when it comes to fields:
public class Test {
private HashMap<String, String> info;
public Test(boolean createInfo) {
if (createInfo) {
info = new HashMap<String, String>();
}
}
}
As you can observe, the HashMap info is initialised if you pass true to Test's constructor.
Does new Test(true) take up more memory than new Test(false)?
Which leads to the more general question:
When you create a field in a class, does Java "reserve" the necessary memory for such field in case it is initialised, or will it do nothing until you actually initialise it?
There is this question: Is memory allocated for unused fields in Java? which seems to be almost exactly what I am looking for, but they seem to be asking what already instantiated fields that are unused, whereas I am asking for uninstantiated fields that may or may not be used.

Does new Test(true) take up more memory than new Test(false)?
Yes.
When you create a field in a class, does Java "reserve" the necessary memory for such field in case it is initialised, or will it do nothing until you actually initialise it?
There are two things here - the HashMap reference, and the HashMap object. Both of them require memory. When a class instance is created, memory is allocated for all its instance variable. In case of int type field, it will allocate 4 bytes, similarly for a reference, it will allocate some memory for that reference (I don't know exactly how much it is). But surely it will allocate memory for the fields.
Then when you initialize the fields in the constructor, the actual HashMap object is created, which will again take up memory to store the object.

The field itself has space for a reference to an object, and that space is allocated when the containing class (Test) is instantiated, even if the value placed in that field is null. Your example code doesn't create an extra object whose reference will go in that field when you pass in false.

Java reusing (static?) objects as temporary objects for performance

I need to call methods of a class with multiple methods very often in a simulation loop.
Some of these methods need to access temporary objects for storing information in them. After leaving the method the stored data is not needed anymore.
For example:
Class class {
method1() {
...
SomeObject temp = new SomeObject();
...
}
method2() {
...
SomeObject temp = new SomeObject();
SomeObject temp2 = new SomeObject();
...
}
}
I need to optimize as much as possible. The most expensive (removable) problem is that too many allocations happen.
I assume it would be better not to allocate the space needed for those objects every time so I want to keep them.
Would it be more efficient to store them in a static way or not?
Like:
Class class {
private (static?) SomeObject temp;
private (static?) SomeObject temp2;
methods...
}
Or is there even a better way? Thank you for your help!
Edit based on answers:
Not the memory footprint is the actual problem but the garbage collection cleaning up the mess.
SomeObject is a Point2D-like class, nothing memory expensive (in my opinion).
I am not sure whether it is better to use (eventually static) class level objects as placeholder or some more advanced method which I am not aware of.

I would be wary in this example of pre-mature optimization. There are downsides, typically, that it makes the code more complex (and complexity makes bugs more likely), harder to read, could introduce bugs, may not offer the speedup you expected, etc. For a simple object such as representing a 2D point coordinate, I wouldn't worry about re-use. Typically re-use gains the most benefit if you are either working with a large amount of memory, avoid lengthy expensive constructors, or are pulling object construction out of a tight loop that is frequently executed.
Some different strategies you could try:
Push responsiblity to caller One way would be to to have the caller pass in an object pre-initialized, making the method parameter final. However, whether this will work depends on what you need to do with the object.
Pointer to temporary object as method parameter Another way would be to have the caller pass as an object as a parameter that's purpose is essentially to be a pointer to an object where the method should do its temporary storage. I think this technique is more commonly used in C++, but works similarly, though sometimes shows up in places like graphics programming.
Object Pool One common way to reuse temporary objects is to use an object pool where objects are allocated from a fixed bank of "available" objects. This has some overhead, but if the objects are large, and frequently used for only short periods of time, such that memory fragmentation might be a concern, the overhead may be enough less to be worth considering.
Member Variable If you are not concerned about concurrent calls to the method (or have used synchronization to prevent such), you could emulate the C++ism of a "local static" variable, by creating a member variable of the class for your storage. It makes the code less readable and slightly more room to introduce accidental interference with other parts of your code using the variable, but lower overhead than an object pool, and does not require changes to your method signature. If you do this, you may optionally also wish to use the transient keyword on the variable as well to indicate the variable does not need to be serialized.
I would shy away from a static variable for the temporary unless the method is also static, because this may have a memory overhead for the entire time your program runs that is undesirable, and the same downsides as a member variable for this purpose x2 (multiple instances of the same class)

Keep in mind that temp and temp2 are not themselves objects, but variables pointing to an object of type SomeObject. The way you are planning to do it, the only difference would be that temp and temp2 would be instance variables instead of local variables. Calling
temp = new SomeObject();
Would still allocate a new SomeObject onto the heap.
Additionally, making them static or instance variables instead of local would cause the last assigned SomeObjects to be kept strongly reachable (as long as your class instance is in scope for instance variables), preventing them from being garbage collected until the variables are reassigned.
Optimizing in this way probably isn't effective. Currently, once temp and temp2 are out of scope, the SomeObjects they point to will be eligible for garbage collection.
If you're still interested in memory optimization, you will need to show what the SomeObject is in order to get advice as to how you could cache the information it's holding.

How large are these objects. It seems to me that you could have class level objects (not necessarily static. I'll come back to that). For SomeObject, you could have a method that purges its contents. When you are done using it in one place, call the method to purge its contents.
As far as static, will multiple callers use this class and have different values? If so, don't use static.

First, you need to make sure that you are really have this problem. The benefit of a Garbage Collector is that it takes care of all temporary objects automatically.
Anyways, suppose you run a single threaded application and you use at most MAX_OBJECTS at any giving time. One solution could be like this:
public class ObjectPool {
private final int MAX_OBJECTS = 5;
private final Object [] pool = new Object [MAX_OBJECTS];
private int position = 0;
public Object getObject() {
// advance to the next object
position = (position + 1) % MAX_OBJECTS;
// check and create new object if needed
if(pool[position] == null) {
pool[position] = new Object();
}
// return next object
return pool[position];
}
// make it a singleton
private ObjectPool() {}
private static final ObjectPool instance = new ObjectPool();
public static ObjectPool getInstance() { return instance;}
}
And here is the usage example:
public class ObjectPoolTest {
public static void main(String[] args) {
for(int n = 0; n < 6; n++) {
Object o = ObjectPool.getInstance().getObject();
System.out.println(o.hashCode());
}
}
}
Here is the output:
0) 1660364311
1) 1340465859
2) 2106235183
3) 374283533
4) 603737068
5) 1660364311
You can notice that the first and the last numbers are the same - the MAX_OBJECTS + 1 iterations returns the same temporary object.