Re: Enums: Properties vs. Methods
On 30 Mrz., 22:17, Lew <l...@lewscanon.com> wrote:
Robert Klemme wrote:
Lew wrote:
You actually don't know what the footprint will be once Hotspot takes
over. With your "toy" example, those booleans might all optimize away
and both cases take the same memory at runtime.
Just so I understand it properly: are you saying that with hotspot the
compiler might remove members of the instances? I am not sure how th=
at
More the other way around: if it sees an opportunity to enregister
members it will remove the instance from the members.
Thanks for clarifying.
would work since then hotspot would need to create several different
versions of the property getter methods (one per instance). I believ=
e
this is not what hotspot can do.
Yes. So? that's what HotSpot does, except it's not one per instance=
,
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?
public void hotSpotMethod(boolean valve_open) {
// code
if (valve_open) {
// ...
}
else {
// ...
}
// more code
}
Considering that there are always only so many instances it seems th=
e
properties approach wins. It seems, custom methods in enum instances
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 would
hotspot be able to inline them?
Here there are boolean properties which derive from the enum, i.e.
whether there is traffic allowed or not and whether the traffic can flo=
w
unlimited.
Now code which uses this enum need not create switches based on concret=
e
enum instances but can use boolean properties in control flow (e.g.
print a warning if no traffic at all is allowed). One might later wa=
nt
THe use of values in a 'switch' doesn't seem relevant to the decision
between your approaches at all.
I never claimed this. This was just an explanation what the boolean
properties were intended for to help make the example better
understandable.
As for JVM effects, I would expect the two approaches to be
indistinguishable. Constant variables are compiled into constants in
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.
Cheers
robert