cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rafaelweingartner <>
Subject [GitHub] cloudstack pull request: Fix Sync of in Swift
Date Mon, 25 Apr 2016 20:23:33 GMT
Github user rafaelweingartner commented on the pull request:
    @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”
    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
    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.

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 or file a JIRA ticket
with INFRA.

View raw message