Who cares about TV? Do people whine about recording the radio on their iPods?
If they get a decent set of shows/movies available, people who don't care about live events like sports may cancel their cable and satellite subscriptions.
Allow me to introduce myself. I am the lead developer of the AMD64 port of the Java JIT compiler developed by a major company. Obviously that doesn't mean my word is gospel on JIT issues. I only hope it will give you pause to think before you dismiss my remarks again.
If you're running on a uniprocessor, the JIT (at least our JIT) never waits for the interpreter. The reasoning is that Java is primarily a server-side technology, and so throughput is paramount. For throughput, once you decide you're going to compile a method, it's always better to compile it before executing it.
The downside of this policy becomes apparent when running an interactive app. The user clicks on a button, causing some Java code to run, causing the invocation counts on some methods fall to zero, causing them to get JITted at precisely the wrong moment, from an interactivity point of view. Just when the user expects a response, the JIT comes along and makes her wait.
Obviously other policies are possible for interactive apps, and some other JVMs probably use such policies. We may start employing such a policy in a future release.
Also, on a multiprocessor (even with hyperthreading or multi-core processors) this is usually no longer a problem because, as you say, one thread will continue interpreting the method while another compiles it.
However, with modern JVMs, with generational concurrent garbage collection... If you're noticing GC pauses, you may not be using your JVM's best available GC policy.
So call System.gc() at the end of each page. Then the only reason it should happen again mid-page is if you actually run out of memory, and then it's unavoidable.
Some queries that Google Local can't handle...
on
Google Maps Graduates
·
· Score: 1
Nice dream , meanwhile in the real world both users and most coders
(if they dare to admit it) will NOT sacrfice usability or ease of
coding for security measures that (in their minds) are nothing to
do with their application.
Really? And I guess you have asked "most coders" for their opinion on this?
You can't write a high-performing JIT compiler with pages using memory that's not writable and executable at the same time. The dynamic nature of Java necessitates continual patching of the generated code for a number of reasons. Even if there were no page-boundary problem (ie. making one page unexecutable could affect any number of methods) and no threading problem (ie. making a page unexecutable would affect every thread executing code on that page) it would still be infeasible to do all those extra system calls every time the generated code needs modifying.
If specs were 100% accurate, then there would not be a need to write the code, because the specs could be automatically translated to code (we are talking about 100% accuracy here, not 99.999999%).
That's not true. If it were, then you could prove P = NP and you'd be famous.
The spec for sqrt(x) says that result*result=x (for complex x). Any compiler smart enough to turn this spec into an implementation of sqrt would be more complex than simply implementing sqrt itself.
Its a bit like comparing an object thrown in the air with an aircraft.
I wouldn't say that's fair. It's more like comparing an aircraft with the General Lee jumping over a broken bridge. SpaceShipOne reached space under its own power; it wasn't "thrown".
Indeed. If people would just realize that you need to corroborate Wikipedia facts before relying on them, almost all the arguments against it would evaporate.
I was impressed that there was practically no degradation when moving from 32-bit to 64 bit. That means there's no real obstacle to adopting 64-bit OSes and apps.
If you have multi-megabyte data structures (eg in a large cache to reduce db traffic) then I'd be very surprised if you had that many pointers relative to actual data.
Join the club. Based on the responses I've received, it seems everyone's surprised. All I can say is, go do the measurements yourself.
Anyway, I think your statement says a lot. It's as though you don't think pointers are "actual data". That might explain your surprise: you think half of the data in a Java heap is wasted.
Slashdot Mirror
If they get a decent set of shows/movies available, people who don't care about live events like sports may cancel their cable and satellite subscriptions.
So people who can't afford high-end photography equipment shouldn't expect their camera to behave as advertised?
If you're running on a uniprocessor, the JIT (at least our JIT) never waits for the interpreter. The reasoning is that Java is primarily a server-side technology, and so throughput is paramount. For throughput, once you decide you're going to compile a method, it's always better to compile it before executing it.
The downside of this policy becomes apparent when running an interactive app. The user clicks on a button, causing some Java code to run, causing the invocation counts on some methods fall to zero, causing them to get JITted at precisely the wrong moment, from an interactivity point of view. Just when the user expects a response, the JIT comes along and makes her wait.
Obviously other policies are possible for interactive apps, and some other JVMs probably use such policies. We may start employing such a policy in a future release.
Also, on a multiprocessor (even with hyperthreading or multi-core processors) this is usually no longer a problem because, as you say, one thread will continue interpreting the method while another compiles it.
However, with modern JVMs, with generational concurrent garbage collection... If you're noticing GC pauses, you may not be using your JVM's best available GC policy.
I wouldn't do it before each page. Then the time consumed by GC is on the critical path for the user's perception of latency.
So call System.gc() at the end of each page. Then the only reason it should happen again mid-page is if you actually run out of memory, and then it's unavoidable.
- mount rushmore
- c n tower
- leaning tower of pisa
- sphynx
I'd say it should have stayed in beta a bit longer.Substantially better than the first, I thought. (And I thought the first wasn't too bad either.)
You can't write a high-performing JIT compiler with pages using memory that's not writable and executable at the same time. The dynamic nature of Java necessitates continual patching of the generated code for a number of reasons. Even if there were no page-boundary problem (ie. making one page unexecutable could affect any number of methods) and no threading problem (ie. making a page unexecutable would affect every thread executing code on that page) it would still be infeasible to do all those extra system calls every time the generated code needs modifying.
Do you have a point?
2 Faster and Like 5 Times More Furiouser?
The spec for sqrt(x) says that result*result=x (for complex x). Any compiler smart enough to turn this spec into an implementation of sqrt would be more complex than simply implementing sqrt itself.
Here is the tail end of the search, sorted by date.
Indeed. If people would just realize that you need to corroborate Wikipedia facts before relying on them, almost all the arguments against it would evaporate.
Give it some time. I'll be pretty surprised if Firefox's rate of security flaws doesn't fall way below IE's over time.
Hey, you fire... Look at your life! What have you done with yourself! You're a loser and nobody will ever love you.
Do you have a point?
What part of their method makes it inapplicable to hunt-'n'-peck typists?
The whole point is that they use smart algorithms to learn what sounds your particular keyboard makes.
The GPL just says if you give the binary, you must give the source too.
I was impressed that there was practically no degradation when moving from 32-bit to 64 bit. That means there's no real obstacle to adopting 64-bit OSes and apps.
Anyway, I think your statement says a lot. It's as though you don't think pointers are "actual data". That might explain your surprise: you think half of the data in a Java heap is wasted.