Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15821 > unrolled thread

Java processors

Back to article view | Back to comp.lang.java.programmer

Contents

  Java processors bob smith <bob@coolfone.comze.com> - 2012-07-05 08:01 -0700
    Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-05 11:28 -0400
      Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 13:00 -0500
        Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-05 14:31 -0400
          Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 16:42 -0500
          Re: Java processors Arne Vajhøj <arne@vajhoej.dk> - 2012-07-05 20:30 -0400
            Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 21:12 -0500
            Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-06 00:13 -0400
              Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:26 -0700
                Re: Java processors Gene Wirchenko <genew@ocis.net> - 2012-07-06 13:50 -0700
                  Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-06 14:17 -0700
                    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:07 -0700
                      Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-07 09:34 -0500
                        Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-07 21:01 -0700
                          Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-08 00:28 -0500
                            Re: Java processors Lew <noone@lewscanon.com> - 2012-07-07 23:00 -0700
                              Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-08 10:20 -0500
                                Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 09:16 -0700
                              Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-08 17:46 +0000
                                Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 11:52 -0700
                                  Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-08 21:41 +0000
                                    Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 17:56 -0700
                                      Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 19:44 -0700
                                        Re: Java processors Lew <noone@lewscanon.com> - 2012-07-09 23:41 -0700
                                      Re: Java processors David Lamb <dalamb@cs.queensu.ca> - 2012-07-16 13:22 -0400
                                        Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-16 14:03 -0700
                                  Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 19:42 -0700
                      Re: Java processors Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-10 01:13 +0200
                        Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-09 16:26 -0700
                        Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-11 15:41 -0700
                          Re: Java processors Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-12 01:02 +0200
                        Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-21 18:46 +0200
                          Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-21 13:05 -0400
                            Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-21 19:23 +0200
                              Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-21 14:10 -0400
                                Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-23 01:17 +0200
                                  Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-22 20:15 -0400
                          Re: Java processors Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-22 15:13 +0200
                  Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:03 -0700
                    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 19:51 -0700
                Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-07 21:17 -0700
                  Re: Java processors Lew <noone@lewscanon.com> - 2012-07-07 23:04 -0700
                    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 09:29 -0700
                      Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 11:57 -0700
              Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-08 15:40 +0200
                Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-08 10:36 -0500
            Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-06 11:31 -0700
        Re: Java processors Jim Janney <jjanney@shell.xmission.com> - 2012-07-05 13:02 -0600
          Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 16:09 -0500
          Re: Java processors Jan Burse <janburse@fastmail.fm> - 2012-07-06 01:29 +0200
            Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-06 00:42 +0000
              Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:53 -0700
                Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-06 21:18 +0000
                  Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-06 18:17 -0400
                    Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-06 22:29 +0000
                    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:10 -0700
                      Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-07 09:42 -0500
                        Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 10:58 -0400
                      (OT) Was: Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 11:38 -0400
                        Re: (OT) Was: Re: Java processors Gene Wirchenko <genew@ocis.net> - 2012-07-07 21:19 -0700
                          Re: (OT) Was: Re: Java processors "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-07-08 12:15 +0200
                      Re: Java processors Gene Wirchenko <genew@ocis.net> - 2012-07-07 21:17 -0700
            Re: Java processors Jim Janney <jjanney@shell.xmission.com> - 2012-07-05 19:14 -0600
          Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:34 -0700
            Re: Java processors Jan Burse <janburse@fastmail.fm> - 2012-07-06 23:04 +0200
              Re: Java processors Silvio Bierman <silvio@moc.com> - 2012-07-07 00:13 +0200
                Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:16 -0700
                  Re: Java processors "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-07-08 11:37 +0200
        Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:24 -0700
          Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-07 10:06 -0500
    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 05:22 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#15881

On Sun, 08 Jul 2012 11:52:52 -0700, Lew wrote:

> Martin Gregorie wrote:
>> Lew wrote:
>>> HotSpot also will "unJIT" code - go back to the interpreted bytecode
>>> and drop the machine-code compilation - when circumstances change.
>>>
>> In view of this, why are we assuming that the JIT stops a method in its
>> tracks, compiles a native version and continues execution in that from
>> the stopping point? Are we sure that it doesn't do something along the
> 
> "We"?
> 
> I, at least, make no such assumption.
>
Fair enough: not you, but several here have been assuming that this 
bytecode to native code switch occurs despite the obvious difficulties of 
doing so.
  
> As I understand the white papers, HotSpot, at least, does not stop the
> interpreter while it's compiling, but does background compilation.
>
I wondered about this, but as it could cause potential conflicts if JIT 
compilation takes significantly longer than interpreted execution of the 
code section (the normal case?), described a stopping scenario because it 
can't cause that sort of problem.
    
> I don't have a reference handy just now, but HotSpot does do something
> like the flip you describe, save for the "stopping bytecode" part, IIRC.
> 
Interesting. If recompilation is needed, is more than one recompiled 
version kept at a time or does the system switch back to bytecode while 
the recompilation runs? Is there any data on the frequency of 
recompilation vs the initial JIT pass? If its quite infrequent, then 
temporary reversion to bytecode may be a worthwhile strategy, especially 
if the recompilation isn't restricted to exactly the same set of bytecode 
instructions.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#15883

Martin Gregorie wrote:
> Lew wrote:
>> Martin Gregorie wrote:
>>> Lew wrote:
>>>> HotSpot also will "unJIT" code - go back to the interpreted bytecode
>>>> and drop the machine-code compilation - when circumstances change.
>>>>
>>> In view of this, why are we assuming that the JIT stops a method in its
>>> tracks, compiles a native version and continues execution in that from
>>> the stopping point? Are we sure that it doesn't do something along the
>>
>> "We"?
>>
>> I, at least, make no such assumption.
>>
> Fair enough: not you, but several here have been assuming that this
> bytecode to native code switch occurs despite the obvious difficulties of
> doing so.

It's not the switch I don't assume, it's the "stop the bytecode" part, as I 
have now posted many times in this thread.

I'm also not assuming anything at all, because I am simply repeating what is 
in the documentation. I'm not spouting "it is likely that" stuff off the top 
of my head without looking up the citations I've provided.
Furthermore I've been going back and reading the documentation as we discuss 
this matter. Perhaps I am alone in this practice?

Those making unfounded assumptions could resolve their confusion by reading 
the available literature. Then instead of assumptions and "it is likely that" 
supposition, one would have certain knowledge and conclusions.

>> As I understand the white papers, HotSpot, at least, does not stop the
>> interpreter while it's compiling, but does background compilation.
>>
> I wondered about this, but as it could cause potential conflicts if JIT
> compilation takes significantly longer than interpreted execution of the
> code section (the normal case?), described a stopping scenario because it
> can't cause that sort of problem.

Apparently it does not cause conflicts, as the HotSpot folks repeatedly tell 
us that they do this with no harm at all to program semantics.

In fact, the point you raise is the motivation to have compilation occur 
concurrently with interpreted execution. The fact that it takes a while to 
analyze for hot spots, much less compile them, is relevant to the fact that 
HotSpot takes a while to analyze for hot spots, much less compile them. Doing 
it in the background gives it the freedom to take that while.

>> I don't have a reference handy just now, but HotSpot does do something
>> like the flip you describe, save for the "stopping bytecode" part, IIRC.
>>
> Interesting. If recompilation is needed, is more than one recompiled
> version kept at a time or does the system switch back to bytecode while
> the recompilation runs? Is there any data on the frequency of

The latter.

It wouldn't make sense to keep old compilations around. They're based on 
runtime conditions that by definition have changed or the old one would still 
be valid. There is no way for the system to predict if those same runtime 
conditions will pertain in the future, nor that it would be worth the memory 
and analytical power to decide if it did, since such analysis is the larger 
part of HotSpot compilation to begin with.

In any event, the white paper to which I linked and other sources talk about 
simply dropping the compiled code and going back to interpreted until the spot 
gets hot enough again to recompile it.

> recompilation vs the initial JIT pass? If its quite infrequent, then

HotSpot is not a JIT compiler.

> temporary reversion to bytecode may be a worthwhile strategy, especially

It might be permanent, that reversion.

> if the recompilation isn't restricted to exactly the same set of bytecode
> instructions.

It isn't, nor is it guaranteed to occur for anything close to that same set again.

And it's not just the instructions. It's the runtime profile, such as whether 
other threads are active for the critical section, or there are aliases for 
key references, or whether they escape the current context just now, or ... 
Plus it only applies to sections of code that the internal profiler reveals to 
matter, the eponymous hot spots.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#15885

On Sun, 08 Jul 2012 17:56:08 -0700, Lew <noone@lewscanon.com> wrote,
quoted or indirectly quoted someone who said :

>It wouldn't make sense to keep old compilations around.

The whole reason to abandon them is because they are ram pigs. Holding
onto them would defeat that purpose.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15911

Roedy Green wrote:
> Lew wrote, quoted or indirectly quoted someone who said :
>
>> It wouldn't make sense to keep old compilations around.
>
> The whole reason to abandon them is because they are ram pigs. Holding
> onto them would defeat that purpose.

No, that's only three quarters of the reason.

The other quarter is the uselessness of optimized code that isn't needed 
because the scenario for which it's optimized has vanished.

The point of caching the compilation would be to take advantage of its 
recurrence. But the code was invalidated for its runtime assumptions no longer 
pertaining.

It takes a while for a hot spot to settle into a position of prominence. So 
the optimization had to have been pretty useful for a while to even exist. For 
it to become invalid, some hefty changes had to have occurred, such as an 
addition of another reference to a previously enregistered value or a new 
thread-contention profile.

For that previously-invalidated compilation to have value again, the runtime 
circumstances would have to shift again in its favor, and persist for a while 
to make it a hot spot.

Cross the probability of that happening with the long time before the "cached" 
compilation can return to play, with ample resources available to profile and 
analyze the hot spot that's required even if you think you have a "cache", and 
you see why it isn't just memory parsimony at play. It's the whole, "Why 
manage a cache that doesn't with complexity that buys you nothing?" philosophy.

Code complexity, lack of benefit, maintenance costs and likelihood of bugs or 
even degraded performance might even outweigh memory parsimony as 
considerations. I'm guessing the HotSpot engineers simply didn't want to 
implement a dumb-ass mechanism.
-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#16046

On 08/07/2012 8:56 PM, Lew wrote:
> It wouldn't make sense to keep old compilations around. They're based on
> runtime conditions that by definition have changed or the old one would
> still be valid.

It has been a long time since I worked on optimizing compiler 
technology, but my fragmented memories suggest that it's not "all or 
nothing" with regard to what information you need for optimization. Some 
intra-procedural data flow analysis remains valid even if 
inter-procedural or inter-class information changes, and some 
optimization only depend on local information.

[toc] | [prev] | [next] | [standalone]

#16053

On Monday, July 16, 2012 10:22:21 AM UTC-7, David Lamb wrote:
> On 08/07/2012 8:56 PM, Lew wrote:
> > It wouldn't make sense to keep old compilations around. They're based on
> > runtime conditions that by definition have changed or the old one would
> > still be valid.
> 
> It has been a long time since I worked on optimizing compiler 
> technology, but my fragmented memories suggest that it's not "all or 
> nothing" with regard to what information you need for optimization. Some 
> intra-procedural data flow analysis remains valid even if 
> inter-procedural or inter-class information changes, and some 
> optimization only depend on local information.

I said "compilations". You said "optimizations".

Apples. Oranges.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15884

On Sun, 08 Jul 2012 11:52:52 -0700, Lew <noone@lewscanon.com> wrote,
quoted or indirectly quoted someone who said :

>"The compiler must not only be able to detect when these optimizations become 
>invalid due to dynamic loading, but also be able to undo or redo those 
>optimizations during program execution, even if they involve active methods on 
>the stack. This must be done without compromising or impacting Java 
>technology-based program execution semantics in any way."

For example, if there is no overriding method, a method can
temporarily  be treated as final. But when some overriding class is
loaded, the assumption has to be undone.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15903

On 07/07/2012 04:07, Roedy Green allegedly wrote:
> On Fri, 6 Jul 2012 14:17:40 -0700 (PDT), Lew <lewbloch@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
> 
>>
>> They don't do that exactly. There's no restart.
>>
>> <http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_warmup>
> 
> " HotSpot contains On Stack Replacement technology which will compile
> a running (interpreted) method and replace it while it is still
> running in a loop. No need to waste your applications time warming up
> seemingly infinite (or very long running) loops in order to get better
> application performance."
> 
> It thus stops it is mid flight, possibly half way through a loop,
> writes machine code, creates the equivalent state/register, and picks
> up where it left off (what I ambiguously called restarting) but
> running machine code.  I can hardly believe this is possible,
> especially when you think about all the optimisations on the machine
> code.

Sounds to me like you could be misinterpreting that, Roedy. It says
"method... running in a loop". Not: loop running in a method. I'd rather
interpret that as being about a method running repeatedly in a loop.

Agree with the "walk on water" thing, though.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#15905

Daniele Futtorovic wrote:
> Roedy Green allegedly wrote:
> Lew wrote, quoted or indirectly quoted someone who said :
> >> They don't do that exactly. There's no restart.
> >>
> >> <http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_warmup>
> > 
> > " HotSpot contains On Stack Replacement technology which will compile
> > a running (interpreted) method and replace it while it is still
> > running in a loop. No need to waste your applications time warming up
> > seemingly infinite (or very long running) loops in order to get better
> > application performance."
> > 
> > It thus stops it is mid flight, possibly half way through a loop,
> > writes machine code, creates the equivalent state/register, and picks
> > up where it left off (what I ambiguously called restarting) but
> > running machine code.  I can hardly believe this is possible,
> > especially when you think about all the optimisations on the machine
> > code.
> 
> Sounds to me like you could be misinterpreting that, Roedy. It says
> "method... running in a loop". Not: loop running in a method. I'd rather
> interpret that as being about a method running repeatedly in a loop.
> 
> Agree with the "walk on water" thing, though.

As cited upthread:
<http://www.oracle.com/technetwork/java/whitepaper-135217.html#optimizations>

Loop unrolling is one of the optimizations mentioned.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15955

On Tue, 10 Jul 2012 01:13:06 +0200, Daniele Futtorovic
<da.futt.news@laposte-dot-net.invalid> wrote, quoted or indirectly
quoted someone who said :

>Sounds to me like you could be misinterpreting that, Roedy. It says
>"method... running in a loop". Not: loop running in a method. I'd rather

That would be much simpler. That way you would never optimise a loop
in the process of being executed.  That sounds like a much more
plausible task.  All you have to do is get the stack right and leave
all the class and instance variable where they are.
 
The problem it is could wait quite a long time to interrupt. I wonder
how it actually works. 
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Mathematicians and computer scientists are far more interested 
in impressing you than informing you. If this were not
so, the tutorials on building a robots.txt file, for example,
would consist primarily of an annotated example. What you get 
instead are nothing but inscrutable adstract fragments in some 
obscure dialect of BNF.

[toc] | [prev] | [next] | [standalone]

#15961

On 12/07/2012 00:41, Roedy Green allegedly wrote:
> On Tue, 10 Jul 2012 01:13:06 +0200, Daniele Futtorovic
> <da.futt.news@laposte-dot-net.invalid> wrote, quoted or indirectly
> quoted someone who said :
> 
>> Sounds to me like you could be misinterpreting that, Roedy. It says
>> "method... running in a loop". Not: loop running in a method. I'd rather
> 
> That would be much simpler. That way you would never optimise a loop
> in the process of being executed.  That sounds like a much more
> plausible task.  All you have to do is get the stack right and leave
> all the class and instance variable where they are.
>  
> The problem it is could wait quite a long time to interrupt. I wonder
> how it actually works. 

Well, look at it like this: the longer (and hence less frequently) the
method runs (it running indefinitely being the extreme case), the less
reason there is to replace it.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#16187

In article <jtfokt$iae$1@dont-email.me>, da.futt.news@laposte-dot-
net.invalid says...

> Sounds to me like you could be misinterpreting that, Roedy. It says
> "method... running in a loop". Not: loop running in a method.

Which loop is not running in a method?

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#16190

On 7/21/2012 12:46 PM, Wanja Gayk wrote:
> In article <jtfokt$iae$1@dont-email.me>, da.futt.news@laposte-dot-
> net.invalid says...
>
>> Sounds to me like you could be misinterpreting that, Roedy. It says
>> "method... running in a loop". Not: loop running in a method.
>
> Which loop is not running in a method?

	class Clown {
	    static {
	        while(true) System.out.println("This one.");
	    }
	}

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#16193

In article <juenhg$3jn$1@dont-email.me>, esosman@ieee-dot-org.invalid 
says...

> >> Sounds to me like you could be misinterpreting that, Roedy. It says
> >> "method... running in a loop". Not: loop running in a method.
> >
> > Which loop is not running in a method?
> 
> 	class Clown {
> 	    static {
> 	        while(true) System.out.println("This one.");
> 	    }
> 	}

Which, from a VM point of view, is nothing else than an anonymous static 
initializer method.

Kind regards,
Wanja


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#16197

On 7/21/2012 1:23 PM, Wanja Gayk wrote:
> In article <juenhg$3jn$1@dont-email.me>, esosman@ieee-dot-org.invalid
> says...
>
>>>> Sounds to me like you could be misinterpreting that, Roedy. It says
>>>> "method... running in a loop". Not: loop running in a method.
>>>
>>> Which loop is not running in a method?
>>
>> 	class Clown {
>> 	    static {
>> 	        while(true) System.out.println("This one.");
>> 	    }
>> 	}
>
> Which, from a VM point of view, is nothing else than an anonymous static
> initializer method.

     I hadn't thought it necessary to be so explicit, but okay:

	class Clown {
	    static {
	        while(true) System.out.println(":)");
	    }
	}

(Sigh.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#16235

In article <juerbe$qpi$1@dont-email.me>, esosman@ieee-dot-org.invalid 
says...

> > Which, from a VM point of view, is nothing else than an anonymous static
> > initializer method.
> 
>      I hadn't thought it necessary to be so explicit, but okay:
> 
> 	class Clown {
> 	    static {
> 	        while(true) System.out.println(":)");
> 	    }
> 	}
> 
> (Sigh.)

throw new JokeDetectorTemporallyUnavailableException("Brain on 
standby.");

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#16238

On 7/22/2012 7:17 PM, Wanja Gayk wrote:
> In article <juerbe$qpi$1@dont-email.me>, esosman@ieee-dot-org.invalid
> says...
>
>>> Which, from a VM point of view, is nothing else than an anonymous static
>>> initializer method.
>>
>>       I hadn't thought it necessary to be so explicit, but okay:
>>
>> 	class Clown {
>> 	    static {
>> 	        while(true) System.out.println(":)");
>> 	    }
>> 	}
>>
>> (Sigh.)
>
> throw new JokeDetectorTemporallyUnavailableException("Brain on
> standby.");

     In fairness, I suppose the expression "class clown" may be
an Americanism, a slang usage not covered in textbooks that even
the most assiduous and capable student might read. We all reveal
our insularities in a multitude of ways, and perhaps even more
obviously when we're trying to be "funny."  Sorry for any offense.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#16215

On 21/07/2012 18:46, Wanja Gayk allegedly wrote:
> In article <jtfokt$iae$1@dont-email.me>, da.futt.news@laposte-dot-
> net.invalid says...
> 
>> Sounds to me like you could be misinterpreting that, Roedy. It says
>> "method... running in a loop". Not: loop running in a method.
> 
> Which loop is not running in a method?

Here's one: <http://physics.gu.se/LISEBERG/tf/loop.jpg>

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#15852

On Fri, 06 Jul 2012 13:50:17 -0700, Gene Wirchenko <genew@ocis.net>
wrote, quoted or indirectly quoted someone who said :

>     Do you have a cite for that?  Restarting a method could be messy.
>Imagine if files are opened, other objects created, etc.

It was probably at a lecture at Java One or at the Colorado software
conference.  I got to ask Bill Joy a number of questions. It might
have been that day.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15886

On Fri, 06 Jul 2012 19:03:30 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>It was probably at a lecture at Java One or at the Colorado software
>conference.  I got to ask Bill Joy a number of questions. It might
>have been that day.

http://www.oracle.com/technetwork/java/whitepaper-135217.html#3
says the optimisations done include:

Deep inlining and inlining of potentially virtual calls: as described
above, method inlining combined with global analysis and dynamic
deoptimization are used by both the client and server compilers to
enable deep inlining and therefore elimination of a substantial amount
of method call overhead. 

Fast instanceof/checkcast: the Java HotSpot VM and compilers support a
novel technique for accelerating the dynamic type tests frequently
required by the Java programming language for type safety. This
further decreases the run-time cost of programming in object-oriented
style. 

Range check elimination: The Java programming language specification
requires array bounds checking to be performed with each array access.
An index bounds check can be eliminated when the compiler can prove
that an index used for an array access is within bounds. 

Loop unrolling: the Server VM features loop unrolling, a standard
compiler optimization that enables faster loop execution. Loop
unrolling increases the loop body size while simultaneously decreasing
the number of iterations. Loop unrolling also increases the
effectiveness of other optimizations. 

Feedback-directed optimizations: the Server VM performs extensive
profiling of the program in the interpreter before compiling the Java
bytecode to optimized machine code. This profiling data provides even
more information to the compiler about data types in use, hot paths
through the code, and other properties. The compiler uses this
information to more aggressively and optimistically optimize the code
in certain situations. If one of the assumed properties of
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web