Github user rafaelweingartner commented on the pull request:
https://github.com/apache/cloudstack/pull/1331#issuecomment-214509189
@jburwell, @syed, sorry the long post, I did a research on a few thing and
I would like to share with you guys.
I was just looking at the state of this PR, and I noticed that the number
of lines added jumped to 300+; most of those lines are needed in order to write
a test case using the âTestAppenderâ approach.
Please do not take me in a bad way; I find discussions like this very
healthy for the future of the project. I also know that the class
âTestAppenderâ is there to be reused in some other tests that want to check
the use of log; but still, it feels pretty complicated to me. Giving that, do
you see why when I created the test as an example for @Syed, I used the Mocking
approach? It feels simpler and more natural to write tests using that approach,
at least to me.
Additionally, I was curious when you mentioned that the use of âstatic
finalâ delimiters could optimize the GC, given that it (the GC) would not
check if those attributes have or not to be garbage collected. I had never
heard that before, so I tried to find something online. If you have some
reliable reference about that, could you share?
I tried to find some specs or guideline documents from either Oracle or
OpenJDK without much success. However, I found something like you said to the
android JVM [1], but that would not be our case. Then, I read some articles
(not scientific ones) from IBM [2] and Oracle [3] about the tuning of java
code. But still, they did not mention anything related to what you said. Then,
I decided to revisit a forum that I did not visit for a long time, since the
time of my first Java certification (I am definitely getting old :(), the
coderanch [4]. There I found something that may be related to what you said
[5]. There was a discussion there about the GC and static variables; at some
point, someone highlights that âStatic variables are destroyed when the class
is unloadedâ. After that, I also found this [6] on Stack overflow, in which
it is described that âStatic variables cannot be elected for garbage
collection while the class is loaded. They can be collected when the respective
class loader (that was responsible for loading this class) is itself
collected for garbage.â. I believe that was the point you wanted to make,
right? Static variables are not GCed by the GC, they are not even checked.
If that was the case, it would have nothing to do with the âfinalâ word
per se, but rather with the use of the âstaticâ word.
After having said that, perhaps we could benefit from both words? I mean we
could still use the âLoggerâ variable as static, but not final; then, we
would be able to write a test case using Mockito (as the first example I
presented to @Syed), which would add less code.
What do you think about that?
Additionally, I had taken a look at some spring framework code. Their
framework is not only the base of ACS but also many other huge projects; so, I
thought it would be interesting to see how they use the logger variables. They
use their âloggerâ attributes as Object variables and not Classes. With
that approach when you extend their code, you âget for freeâ a logger
instance to be used. I believe that is why I am so used to loggers being object
attributes. I might have been working too much with their components and
frameworks.
When we do that, we can avoid the following example that happens in ACS:
Letâs take the example of âNfsSecondaryStorageResourceâ class. That
class is an intermediate class to singletons (LocalNfsSecondaryStorageResource,
MockLocalNfsSecondaryStorageResource, PremiumSecondaryStorageResource and
SimulatorSecondaryStorageResource). All of them also have a Logger instance for
their respective class. Also, the âNfsSecondaryStorageResourceâ extends the
âServerResourceBaseâ that has a Logger instance too. In total, we have 5
Logger instances. One for each class, giving that all of them are static
attributes. If we used an approach similar to the one that is used by Spring-*,
we would have one âLoggerâ instance for each singleton, which would
represent 4 logger instances.
I did some tests, and the approximated size of a Logger instance is ~820
bytes. So, if we save the instantiation of a few of this we can reduce a little
bit of the use of ACS memory, giving that due to the way we create âLoggerâ
objects today, we have an instance even for classes that are not object per se,
but intermediated classes in a hierarchy of singletons.
[1] http://developer.android.com/training/articles/perf-tips.html
[2] http://www.ibm.com/developerworks/library/j-jtp01274/
[3]
https://docs.oracle.com/cd/E26576_01/doc.312/e24936/tuning-apps.htm#GSPTG00161
[4] http://www.coderanch.com
[5]
http://www.coderanch.com/t/381848/java/java/Garbage-Collector-Static-Variables
[6]
http://stackoverflow.com/questions/453023/are-static-fields-open-for-garbage-collection
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
