3

I've seen code like this many times where developer creates scope inside a scope.

enter image description here

There are few reasons i can think of:
1. Hiding encapsulating variables of scopes, isolating them. (which also will allow to declare variables with the same name)
2. Allowing allocated memory in scope 1 to be garbage collected when its closed.

However I dont think any of those are sufficient enought to do this...

Whats the point of doing this?

vach
  • 10,571
  • 12
  • 68
  • 106
  • 2
    You'd have to ask the author. It's almost as if he were making 2 separate test methods (which would be understandable), then decided to just forget it, but didn't bother removing the braces. – Kayaman Nov 30 '15 at 13:44
  • 2
    Could you post the code inside the question and not as screen-shot? – Tunaki Nov 30 '15 at 13:44
  • 4
    Let's say you leave out these brackets. If you're allocating a lot of memory in the first block and make a very long calculation in the second block you'll occupy that memory from the first block a long time (which will make your point 2. sufficient enough to do this...) – ParkerHalo Nov 30 '15 at 13:46
  • I do this a lot. I don't like to leak variables into scope. If it's only ever used once then coding in a method obfuscates, and in a reflective language like Java could introduce unwanted dependency. – Bathsheba Nov 30 '15 at 13:47
  • Ok a better question then : if the first scope is allocating memory on stack, is it guaranteed that when the scope closes it will free that memory? cos if it is that makes perfect sense, altough even without scopes compiler would figure it out... – vach Nov 30 '15 at 13:49
  • 4
    Nope. But the stuff in the first scope will be eligible for garbage collection. – Bathsheba Nov 30 '15 at 13:49
  • 3
    @vach No, it's not guaranteed that "it will free that memory". It is guaranteed that it is eligible for garbage collection. – Seelenvirtuose Nov 30 '15 at 13:50
  • @Bathsheba there is no garbage collection on stack, if jit optimized few object allocation to stack allocation then GC is not working with that memory, as far as i know it will be cleared from stack as soon as scope closes... – vach Nov 30 '15 at 13:52
  • 1
    That's incorrect. Remember that you're referring to *objects*. Indeed a reference will go out of scope, the reference count will drop to 0, but that does *not* trigger an immediate deletion of the object. – Bathsheba Nov 30 '15 at 13:55
  • @Bathsheba if your object is stack confined (you dont leak the reference out of its scope) then JIT is most likely to replace object allocation with stack allocation, therefore you wont have any object created, therefore no GC is to be waited for... My point is if you know it is stack confined does the closing of the scope clear the stack or not? – vach Nov 30 '15 at 13:57
  • Some would say it improves readability and keeps the code organized. I personally disagree, since it is really uncommon, thus it achieves the opposite (i.e. people staring at the code wondering 'wtf..?') – francesco foresti Nov 30 '15 at 13:57
  • Scope is unrelated to garbage collection. Scope is a compile time concept regarding names. – Sotirios Delimanolis Nov 30 '15 at 14:32
  • @SotiriosDelimanolis do you mean that at runtime there will be nothing indicating about those scopes? like you never even wrote them? – vach Nov 30 '15 at 14:36
  • More or less. Scope just doesn't regulate GC. – Sotirios Delimanolis Nov 30 '15 at 14:39
  • Ok guys can anyone answer for sure if closing a scope frees the portion of the stack memory used for that scope? ( i cannot imagine any other way of releasing that memory as there is not GC for stack...) – vach Nov 30 '15 at 14:49
  • My point is that, if you're using a lot of memory and you dont want to go out to heap and rather use stack... then if you help the runtime by freeing the stack before the heavy method finishes you might therefore achieve stack only allocations... (for example if you have 5mb stack, first scope uses 3 and second also 3 you could still stay in stack, while with one scope you would go out to heap)... right? – vach Nov 30 '15 at 14:52

1 Answers1

1

As the Java Language Specification states

The scope of a declaration is the region of the program within which the entity declared by the declaration can be referred to using a simple name, provided it is visible (§6.4.1).

In other words, scope only regulates the use of names within source code. It has no effect on runtime behavior, and therefore has no effect on garbage collection.

Your first suggestion is more or less the only reason to use a block. But some times it gets too cumbersome. Personally, I've maybe used them once or twice in code I've written.

Garbage collection is partly defined by finalization of class instances. That chapter speaks about reachability

A reachable object is any object that can be accessed in any potential continuing computation from any live thread.

The JVM cannot collect such objects.

The JLS also mentions

Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a Java compiler or code generator may choose to set a variable or parameter that will no longer be used to null to cause the storage for such an object to be potentially reclaimable sooner.

This is also discussed in the answer to

Community
  • 1
  • 1
Sotirios Delimanolis
  • 274,122
  • 60
  • 696
  • 724