Skip to main content

Java Quick Starter IO activity question

14 replies [Last post]
kamre
Offline
Joined: 2008-11-23
Points: 0

My question is about jqs.exe IO activity: it seems that it reads about 8Mb from disk every 30 seconds, is this the intended behaviour?

Just look at the history graphics (after several minutes of idle): http://s1.ipicture.ru/uploads/090127/sBvPNweJ33.png
All this IO peaks were from jqs.exe. So it is the only process in the system with such IO activity when computer is idle. And that is rather strange. Probably this not a question for desktop computer, but for laptop this IO activity is not acceptable (I have to turn off JQS on laptop).

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rabbe
Offline
Joined: 2003-06-14
Points: 0

Way to blame marketing for an engineering problem.

JQS is a genuine effort to improve the start-up time of applets and Java applications. Sun Engineers determined (correctly) that the majority of time taken to load Java classes was disk IO. JQS helps relieve this problem by ensuring that the common Java classes loaded by every Java application when launched are preloaded in the disk cache so the host OS doesn't have to go directly to disk.

Just disable JQS if it's causing you problems.

akarl16
Offline
Joined: 2009-01-29
Points: 0

I wasn't blaming, simply questioning and trying to understand the decision to turn it on by default. I fully understand that from the Java runtime perspective this is a benefit and I suppose its a good engineering decision if you make the assumption that JRE startup time should trump overall system performance. I do not agree with that assumption from an overall system engineering perspective and so I have in fact turned it off. I don't mind having the ability to turn this on but I do not agree with the decision to turn it on by default. For a large group of systems that I am supporting, this puts a dent, however small, in the overall system performance. In my mind, the JRE is overstepping its bounds by doing this.

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Have you really been able to measure this performance "dent" supposedly caused by JQS?

akarl16
Offline
Joined: 2009-01-29
Points: 0

To an extent yes. Here is what I base this on.

- I compile all day long and I sit in a large enterprise application all day long so my system does not have lots of extra RAM available.
- When Disk I/O is high, my system performs poorly.
- Large amounts of page faults result in heavy disk I/O for me. I know all of this is fairly obvious and preventable with better hardware.

- There are several processes that tend to cause lots of page faults. Google desktop is one such program. Another is JQS. JQS produces almost as many page faults as Google Desktop.
- Turning JQS off results in less page faulting and less disk IO overall.

I don't have numeric measurements for my overall system performance but I have prevented a significant number of page faults which typically cause me slowdowns. I would expect that the "engineering" that was mentioned earlier did do this sort of measurement. Those findings would be interesting to see.

mthornton
Offline
Joined: 2003-06-10
Points: 0

The page fault count shown by Windows Task Manager is not a very useful indicator, it mostly reflects the internal working of the Windows memory management and doesn't directly correlate to any real work done by the system.

akarl16
Offline
Joined: 2009-01-29
Points: 0

Which is exactly why I correlated immediate page fault deltas with disk IO and then disk IO with real system performance. I would agree that some of this seems circumstantial but on several systems I have seen a noticeable difference in my everyday activities. I will also grant that my everyday activity of compiling large chunks of source code taxes my systems heavily however I think that a large chunk of the JRE user base has weak system specs and so would see similar behavior.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

> From the documentation I've read and what I've observed,
> Java is essentially launching itself constantly so that
> launching it in the future is faster.
Wrong, the only thing JQS does is touching files from time to time needed at Java startup, so that the OS keeps the files in disk cache.

> Which is exactly why I correlated immediate page
> fault deltas with disk IO and then disk IO with real
> system performance.
Page fault != Swapping. As far as I know a pagefault simply indicates, that the processor did not have a requested page in its TLB, which of course if quite likely for IO, the TLB usually handles only a few pages and IO correlates to "large" amount of data.
Page fault simply means the OS was asked which virtual page number corresponds to which real page.

> I will also grant that my everyday
> activity of compiling large chunks of source code
> taxes my systems heavily however I think that a large
> chunk of the JRE user base has weak system specs and
> so would see similar behavior.
JQS reserves about 20mb of your *disk cache*. However JQS does not "steal" memory from your apps.
When you run low on memory, the OS will sacrifice the disk cache to give the apps more RAM.

As always this is tradeof situation. Memory is quite cheap these days and even older systems usually have 512mb or more, for a 512mb system, the 20mb used disk cache is hardly noticeable.
On the other hand systems where each bit of performance counts, are usually way better equipped (my dev laptop has 3GB) ... and to be honest I miss JQS on Linux.

Of course this is a work-arround caused by the weak random IO performance of harddrives, and the large size of the Java runtime. But even the size can't be changed easily, so I for my part I am happy with the solution.
You still can turn it off, if it disturbs your very specific workload. However to be honest I doubt you'll see a significant difference in objective benchmarks.

I've just heard from my customers that they were quite happy when they were upgraded to JDK6u11, especially because of the faster startup of my applet based solution. After all, that was the only change they noticed ;)

- Clemens

fizix
Offline
Joined: 2009-02-08
Points: 0

the resources hit may seem insignificant, and the function easy to turn off, but in practice neither is true.

first, 512M systems may seem to have room for jqs, but typically, 512M systems are running on the edge of max memory usage anyway, especially when browsing the web since every helper-app wants to be resident at all times, not to mention the browser itself. some added application that comes in and sections off ANY portion of non-paged resources causes a noticeable hitch in all the everyday usages.

you would also think this wouldn't have any affect on a core2 duo laptop with 1.5Gs of memory, but it does. bringing up pages, minimizing applications, even using alt-tab to switch focus is different (jerky?) with jqs running. further, i see no difference in jqs's behavior whether my laptop is on battery or plugged in.

which brings us to the second half of the complaint. sure, there is a check box that supposedly turns off jqs, but it only does so for, at most, a day. i've tried turning off the java update manager as well, but for whatever reason, jqs materializes after some short period of time AND the check box is marked again.

now, the only option i'm left with is disabling the service - and that's just not an acceptable recourse, especially when there is a setting in the more obvious java app itself. a more typical user wouldn't know what to do other than uninstall.

so, in summary:

1) turning it on by default is a marketing/competition decision. as people figure out that their older machines seem sluggish because of the decision, and because of java, any benefit there may have been to enabling it by default will probably be reversed. the "people who know" (meaning the people typical users go to for computer help) will tell everyone the way to turn it off, but all that the typical users will hear is that java was to blame.

2) even given some benefit in the decision above, the fact that there is a check box to turn it off THAT DOESN'T WORK is a huge problem. it means that java-dev realized there could be some benefit in allowing users to turn it off, but they couldn't bring themselves to code it properly. that certainly doesn't make the rest of the code look shiny and robust. why would any user want the same people messing up their own code to make decisions about that users memory allocation?

3) again, java-dev indicated that there IS some resources hit in using jqs, because they supposedly turn it off while the pc is on battery power - but they couldn't code that robustly either. another bad mark for the whole project.

java has some real benefits as a platform, but the hand-waving and dismissive arguments adopted here to bless the poor implementation and decision making process involved in adding jqs are just not.... accurate. in addition, the complaints about jqs have a rational and real basis - how many businesses are using old systems in this economic environment, do you think?

i'm still testing to see if the jqs service will be magically enabled from the disabled state depending on whether i leave java updates on or not. we'll see.

akarl16
Offline
Joined: 2009-01-29
Points: 0

Vista/7 does this and I believe JQS is off by default in Vista/7.

The logic of this doesn't click for me. Presumably XP systems are generally slower than Vista systems (in general) so on the systems with the least resources we, by default, force the usage of more system resources. In my case, I have an aging XP system that was made worse overall because of this.

Was this a marketing decision so that Sun could say that "Java now loads faster". If that is the case then I am even more annoyed. I feel like we are missing something because this seems a bit underhanded.

jmelvin
Offline
Joined: 2004-12-01
Points: 0

I can confirm that JQS is disabled for Vista by default, as we see no benefit.
SuperFetch in Vista is much more efficient than the prefetching on XP.

I can also confirm that the decision to implement JQS was not a marketing
decision, but rather a engineering to improve the cold/warm start times for
Java applications and applets. We've carefully considered how much to
prefetch to the disk cache to keep Java fresh for the next invocation.

Although we don't recommend it, savy users can tune the JQS config file
to change the frequency of prefetching and other parameters. As a last
resort, the JQS Windows Service can be disabled manually, or removed
by unchecking the checkbox for JQS in the Advanced tab of the Java
Control Panel. So, there is a fair amount of flexibility here.

akarl16
Offline
Joined: 2009-01-29
Points: 0

I agree with the complaint here. I have turned JQS off on most of my systems now (Windows XP) due to the massive number of page faults that it causes.

From the documentation I've read and what I've observed, Java is essentially launching itself constantly so that launching it in the future is faster. This makes me slightly angry. If Java is pulled out of RAM by the operating system then it probably was in the overall system's best interest to have it pulled out of RAM. I don't agree that Java runtimes are privileged enough that they should begin overriding what my operating system is working hard to accomplish.

mthornton
Offline
Joined: 2003-06-10
Points: 0

On the other hand a lot of other applications (and non core bits of the OS) have been playing this game for some time. The result has been a steady increase in system startup and login times along with higher memory use. So long as this situation continues, Java should be in there too.
Ideally preloading should be managed by the OS and restricted to those applications which you have actually used recently.

kamre
Offline
Joined: 2008-11-23
Points: 0

Well, I would prefer that JQS consumes 20-30Mb at system startup and doesn't not disturb my HDD every 30 seconds.

jmelvin
Offline
Joined: 2004-12-01
Points: 0

Java Quick Starter does refresh the disk cache every 30 seconds. However, if running on battery, the refresh cycle is suspended if the system is idle.