Re: Enums: Properties vs. Methods
On 31 Mrz., 14:41, Lew <no...@lewscanon.com> wrote:
Robert Klemme wrote:
Lew<l...@lewscanon.com> wrote:
Yes. So? that's what HotSpot does, except it's not one per insta=
nce,
it's N>= 1 per instance, potentially. HotSpot optimizes for
individual hot spots in the code, hence the name.
Hmm... Considering
public void hotSpotMethod(Valve v) {
// code
if (v.isOpen()) {
// ...
}
else {
// ...
}
// more code
}
Since this method can be invoked with different Valve instances the
only optimization I can see so far is
public void hotSpotMethod(Valve v) {
// code
if (v.open) {
// ...
}
else {
// ...
}
// more code
}
or are you saying that we can actually get this?
I make no claims whatsoever about individually crafted examples designed =
to
show where HotSpot might fail. I only repeat publicly available inform=
ation
about what it does.
These examples were not crafted to show where HotSpot fails but to
learn what kind of optimizations you had in mind. I went from
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.html
and found
http://www.oracle.com/technetwork/java/whitepaper-135217.html#method
http://www.oracle.com/technetwork/java/whitepaper-135217.html#optimizations
which does not give away too much. There's also
http://en.wikipedia.org/wiki/Java_performance
But that did not provide too much insight either.
http://www.google.de/search?q=java+hotspot+optimizations
Wasn't too good either. What public resources did you have in mind?
public void hotSpotMethod(boolean valve_open) {
// code
if (valve_open) {
// ...
}
else {
// ...
}
// more code
}
...
Yes, it wins, but that has nothing to do with memory or performance in
the JVM.
For the toy example given I would expect no difference, since the
final variables ocmpile to constants anyway.
But those final variables are only constant /per instance/. How woul=
d
hotspot be able to inline them?
Per instance, or perhaps per call. Of course. It might then un-inli=
ne them
for a later call, then re-inline them - even the exact same call if condi=
tions
change that affect optimization.
Yes, but frankly, that's too general for me. Can you be more specific
with regard to the current case we are discussing?
The beauty of HotSpot is that it accounts for changing run-time circumsta=
nces,
so it can perform optimizations that elude static analysis.
Certainly.
You should read about it.
...
As for JVM effects, I would expect the two approaches to be
indistinguishable. Constant variables are compiled into constants i=
n
the code, so they get treated identically with constants (being, after
all, constants in truth) at run time.
I don't think these final members (which are not static!) can be
compiled into the code because there is just one class (and hence one
instance of each method) but multiple instances with different sets of
values for their final members.
The JLS requires them to be compiled into the code. And regardless of =
what
you don't think, that's exactly what happens. You should read about it=
..
Start here: JLS, =A717.5.3, as I cited earlier.
It seems that is not a good place to start (see other postings). :-)
Cheers
robert