Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #2657
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Enums: Properties vs. Methods |
| Date | 2011-03-31 08:26 -0700 |
| Organization | http://groups.google.com |
| Message-ID | <1f76f26d-4b21-4a26-92b4-bb6553b9cad6@f30g2000yqa.googlegroups.com> (permalink) |
| References | (1 earlier) <imsutq$115$1@news.albasani.net> <8vh9efFg01U1@mid.individual.net> <fba37755-efd7-4ff7-a6a7-ee6c48cf7590@hg8g2000vbb.googlegroups.com> <0187eb75-7f36-4254-9711-f63ff480f62e@j13g2000yqj.googlegroups.com> <in1sos$603$1@news.albasani.net> |
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 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?
>
> I make no claims whatsoever about individually crafted examples designed to
> show where HotSpot might fail. I only repeat publicly available information
> 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 would
> > hotspot be able to inline them?
>
> Per instance, or perhaps per call. Of course. It might then un-inline them
> for a later call, then re-inline them - even the exact same call if conditions
> 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 circumstances,
> 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 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.
>
> 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, §17.5.3, as I cited earlier.
It seems that is not a good place to start (see other postings). :-)
Cheers
robert
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-29 08:18 -0700
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-29 11:47 -0400
Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-30 20:00 +0200
Re: Enums: Properties vs. Methods Lew <lew@lewscanon.com> - 2011-03-30 13:17 -0700
Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-31 00:48 -0700
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 08:41 -0400
Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-31 08:26 -0700
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 22:16 -0400
Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-04-02 11:56 +0200
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-04-02 10:29 -0400
Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-04-03 13:14 +0200
Re: Enums: Properties vs. Methods markspace <-@.> - 2011-03-29 09:26 -0700
Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-30 20:06 +0200
Re: Enums: Properties vs. Methods markspace <-@.> - 2011-03-30 12:40 -0700
Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-31 00:38 -0700
Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-29 19:03 +0200
Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-29 19:04 +0200
Re: Enums: Properties vs. Methods Roedy Green <see_website@mindprod.com.invalid> - 2011-03-29 12:49 -0700
Re: Enums: Properties vs. Methods Roedy Green <see_website@mindprod.com.invalid> - 2011-03-29 12:52 -0700
Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-29 22:45 +0200
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-29 17:08 -0400
Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-29 23:25 +0200
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-29 19:05 -0400
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-29 19:40 -0400
Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-31 02:57 -0700
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 08:52 -0400
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 08:54 -0400
Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-30 18:40 +0200
Re: Enums: Properties vs. Methods Lew <lew@lewscanon.com> - 2011-03-30 10:33 -0700
Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-30 20:43 +0200
Re: Enums: Properties vs. Methods Lew <lew@lewscanon.com> - 2011-03-30 13:20 -0700
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 08:55 -0400
Re: Enums: Properties vs. Methods Wanja Gayk <brixomatic@yahoo.com> - 2011-04-02 11:23 +0200
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-04-02 10:36 -0400
Re: Enums: Properties vs. Methods Wanja Gayk <brixomatic@yahoo.com> - 2011-04-02 21:20 +0200
csiph-web