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

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

compile directly into a .zip/.jar file?

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

Contents

  compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-12 12:30 +0000
    Re: compile directly into a .zip/.jar file? Joerg Meier <joergmmeier@arcor.de> - 2014-04-12 15:02 +0200
      Re: compile directly into a .zip/.jar file? Roedy Green <see_website@mindprod.com.invalid> - 2014-04-12 19:56 -0700
        Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 15:29 +0000
      Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 15:19 +0000
        Re: compile directly into a .zip/.jar file? Roedy Green <see_website@mindprod.com.invalid> - 2014-04-13 17:35 -0700
      Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-13 13:53 -0400
        Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 22:21 +0000
          Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-13 18:40 -0400
      Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-13 14:04 -0400
        Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 22:52 +0000
          Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-14 21:41 -0400
            Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-15 12:51 +0000
              Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-15 20:00 -0400
                Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 12:29 +0000
                  Re: compile directly into a .zip/.jar file? Jeff Higgins <jeff@invalid.invalid> - 2014-04-16 10:58 -0400
                    Re: compile directly into a .zip/.jar file? Jeff Higgins <jeff@invalid.invalid> - 2014-04-16 12:45 -0400
                      Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 19:33 +0000
                        Re: compile directly into a .zip/.jar file? Jeff Higgins <jeff@invalid.invalid> - 2014-04-16 15:48 -0400
                        Re: compile directly into a .zip/.jar file? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-04-16 16:20 -0400
                          Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 22:31 +0000
                    Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 18:43 +0000
                  Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-16 18:33 -0400
                    Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-17 12:58 +0000
    Re: compile directly into a .zip/.jar file? Roedy Green <see_website@mindprod.com.invalid> - 2014-04-12 19:54 -0700
      Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 16:08 +0000
    Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-13 23:25 +0000
      Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-14 21:40 -0400
        Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-15 13:38 +0000
          Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-15 19:49 -0400
            Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 12:38 +0000
    Re: compile directly into a .zip/.jar file? Roedy Green <see_website@mindprod.com.invalid> - 2014-04-13 17:38 -0700

Page 1 of 2  [1] 2  Next page →

#28043 — compile directly into a .zip/.jar file?

Is it possible to compile directly into a .zip/.jar file?

This may look odd, as everyone uses ant (or something alike) to do the jarring,
but the problem that I'm trying to solve is, that the (big) number of .class
files in the target folder appears to slow down things to a crawl on AIX (jfs2).

To give an impression: merely running rm -rf on the folder containing the .class
files (about 100,000) takes 13 minutes - and this is on a local filesystem.
Compiling takes 42 mins on that AIX machine, with only 20 minutes accounted
as cpu-time. (on linux, the rm takes a couple of seconds, and compiling takes
18 minutes - almost all of it accounted as cpu-time)

My hope now is, that if I could specify a zip/jar file for the -d option
(doesn't work - already tested) or something similar, then adding files
to a zip might still be faster than the sluggy OS on large directories.

PS: the "obvious" split-it-into-separate-packages is plan Z.
   Plan Y is compiling batches of 100, then adding the results to zip-file,
   and removing the .class files, then go for next batch...
   I do hope for some plans B-X, first, (where plan A was status sluggish quo.)

PPS: I'm not an expert of AIX, so if there are better filesystems than jfs2,
   or mount-options to improve performance with large directories, then that
   would also help a lot.  I know, this is not an AIX group, and my AIX
   whining was mostly to explain why I would want the javac-feature I asked for)

[toc] | [next] | [standalone]

#28044

On Sat, 12 Apr 2014 12:30:12 +0000 (UTC), Andreas Leitgeb wrote:

> Is it possible to compile directly into a .zip/.jar file?

Technically, that would be the same as compiling into a ramdisk, and
zipping that. So why not try to do that ? Ramdisks are pretty generic, so
you might have an easier time finding a solution to what is essentially the
same problem wrapped in Java confines.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#28051

On Sat, 12 Apr 2014 15:02:20 +0200, Joerg Meier <joergmmeier@arcor.de>
wrote, quoted or indirectly quoted someone who said :

>Technically, that would be the same as compiling into a ramdisk, and
>zipping that. So why not try to do that ? Ramdisks are pretty generic, so
>you might have an easier time finding a solution to what is essentially the
>same problem wrapped in Java confines.

SSDs are so cheap now I was able to replace my hard disk with one. I
just use the hard disk as an attic for rarely used files.

see http://mindprod.com/bgloss/ssd.html
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"Don't worry about people stealing an idea; if it's original, you'll
 have to shove it down their throats." 
~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)

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

#28065

Roedy Green <see_website@mindprod.com.invalid> wrote:
> SSDs are so cheap now I was able to replace my hard disk with one. I
> just use the hard disk as an attic for rarely used files.
> see http://mindprod.com/bgloss/ssd.html

In principle you're right...

I'm sure dilbert.com has a couple of stories on how that just
won't happen.  e.g. http://dilbert.com/strips/comic/2007-09-01/

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

#28064

Joerg Meier <joergmmeier@arcor.de> wrote:
> On Sat, 12 Apr 2014 12:30:12 +0000 (UTC), Andreas Leitgeb wrote:
>> Is it possible to compile directly into a .zip/.jar file?
> Technically, that would be the same as compiling into a ramdisk, and
> zipping that.

Other timing experiments, I've made meanwhile, have shown that the
large directory itself doesn't seem to be the problem. (It would
have been more comforting to believe that sluggish performance was
result of some unusal use - like large directories - but unfortunately
sluggish performance seems to be the rule on that system.)

A ramdisk thus sure looks like a more promising approach, than my previous
plans Y & Z (in my OP).  Almost can't wait till monday for trying it.

Thanks!

PS: another approach might be trying option "log=NULL" for some partition
  with less-than-precious data. Btw., also checking the system logs for I/O
  problems on the log device is on the TODO list.

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

#28078

On Sun, 13 Apr 2014 15:19:28 +0000 (UTC), Andreas Leitgeb
<avl@auth.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>
>Other timing experiments, I've made meanwhile, have shown that the
>large directory itself doesn't seem to be the problem.

I remember back in the days of DOS when a customer complained a
machine I had built for him was too slow.  He put 12,000 files about
horse racing in one directory.  Back in the day, directory searches
were linear.

I have been working with the HTMLValidator people to speed up their
program by tracking when files were last verified as error free.  They
were reluctant to use a HashMap, being C++ programmers. I suggested
using a tree of tiny disk files instead. They liked the simplicity of
the idea. However, I was surprised to see they implemented the tree by
converting \ in filenames to _ and storing the tree in one directory.
It is incredibly fast, simply because it avoids revalidating anything
it knows is already good. I wondered which actually would be faster,
tree or their system.  Has anyone ever experimented or have thoughts
on the matter?

A tree would be more compact, and hence more likely to be cached and
more localised. I think modern hashed directories do not slow down
with size.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"Don't worry about people stealing an idea; if it's original, you'll
 have to shove it down their throats." 
~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)

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

#28068

On 4/12/2014 9:02 AM, Joerg Meier wrote:
> On Sat, 12 Apr 2014 12:30:12 +0000 (UTC), Andreas Leitgeb wrote:
>> Is it possible to compile directly into a .zip/.jar file?

Weird - I did not see the original post.

Yes. It is possible.

The javac command does not support it but Java does.

Java has supported a compiler API capable of compiling to a
byte array since 1.6 and supported writing jar files since 1.2.

So all you need to do is to write your own compiler driver with
the command line switches you want and glue everything together.

Arne

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

#28070

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/12/2014 9:02 AM, Joerg Meier wrote:
>> On Sat, 12 Apr 2014 12:30:12 +0000 (UTC), Andreas Leitgeb wrote:
>>> Is it possible to compile directly into a .zip/.jar file?
> Weird - I did not see the original post.

shrug - just missed it, or not available on your server?

> Yes. It is possible.
> The javac command does not support it but Java does.
> Java has supported a compiler API capable of compiling to a
> byte array since 1.6 and supported writing jar files since 1.2.

do you mean:
  http://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html
?

Thanks for bringing it up! I wasn't aware of that until I googled
for "java compiler api" triggered by your answer.

It's always good to know one's options, but I think this is a bit
too much of a detour for me at this point.

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

#28071

On 4/13/2014 6:21 PM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/12/2014 9:02 AM, Joerg Meier wrote:
>>> On Sat, 12 Apr 2014 12:30:12 +0000 (UTC), Andreas Leitgeb wrote:
>>>> Is it possible to compile directly into a .zip/.jar file?
>> Weird - I did not see the original post.
>
> shrug - just missed it, or not available on your server?

Not on my server.

>> Yes. It is possible.
>> The javac command does not support it but Java does.
>> Java has supported a compiler API capable of compiling to a
>> byte array since 1.6 and supported writing jar files since 1.2.
>
> do you mean:
>    http://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html
> ?

Yes.

And even though it is a rather convoluted API making it difficult to
use then compiling to byte array is certainly doable.

> Thanks for bringing it up! I wasn't aware of that until I googled
> for "java compiler api" triggered by your answer.

It did get a little bit of mentioning back when 1.6 came out, but
it is a feature that only a small part of Java developers ever
get a need for.

Arne

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

#28069

On 4/12/2014 9:02 AM, Joerg Meier wrote:
> On Sat, 12 Apr 2014 12:30:12 +0000 (UTC), Andreas Leitgeb wrote:
>> Is it possible to compile directly into a .zip/.jar file?
>
> Technically, that would be the same as compiling into a ramdisk, and
> zipping that.

"the same" is a rather elastic term.

It would avoid writing to a physical disk.

I would not avoid calling down Java->CRT->OS, managing file system
info etc..

If the goal is better performance, then whether using a RAM disk will
be more like using byte[] or like using a traditional rotating hard disk
may depend a lot on hardware, OS, file system and config. RAM access
is many many orders of magnitude faster than access to data on a
rotating disk. But with todays OS/file system caches and disk
caches - likely in write back mode, then writing those class files
to disk may not cause them to be actually written to the rotating plates
before long after the process is completed from user perspective.

Arne

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

#28072

Arne Vajhøj <arne@vajhoej.dk> wrote:
> If the goal is better performance,

It's not like I wanted to squeeze another microsecond out of the
compile time, but more like trying to bypass some brake, that the
system has slammed full on for no good reason.

> But with todays OS/file system caches and disk
> caches - likely in write back mode, then writing those class files
> to disk may not cause them to be actually written to the rotating plates
> before long after the process is completed from user perspective.

Unless, maybe, the system believes that a file write/delete isn't
done until it's physically on the disk and some logs on another...
Kind of like some sync-flag was set. (maybe it even is - hardcoded)

Googling for the symptom I came across suggestions to mount a separate
filesystem over the target folder, and when it's time to clean up, then
just umount,mkfs,mount the partition.  Those people must have been quite
unhappy with their filesystem performance, too, to suggest that.

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

#28086

On 4/13/2014 6:52 PM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> If the goal is better performance,
>
> It's not like I wanted to squeeze another microsecond out of the
> compile time, but more like trying to bypass some brake, that the
> system has slammed full on for no good reason.
>
>> But with todays OS/file system caches and disk
>> caches - likely in write back mode, then writing those class files
>> to disk may not cause them to be actually written to the rotating plates
>> before long after the process is completed from user perspective.
>
> Unless, maybe, the system believes that a file write/delete isn't
> done until it's physically on the disk and some logs on another...
> Kind of like some sync-flag was set. (maybe it even is - hardcoded)

That is how it always was in the old days.

But today aggressive caching is quite common.

And it should be fine for a build server.

Arne

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

#28091

On Mon, 14 Apr 2014 21:41:50 -0400, Arne Vajhøj wrote:

> On 4/13/2014 6:52 PM, Andreas Leitgeb wrote:
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> If the goal is better performance,
>>
>> It's not like I wanted to squeeze another microsecond out of the
>> compile time, but more like trying to bypass some brake, that the
>> system has slammed full on for no good reason.
>>
>>> But with todays OS/file system caches and disk caches - likely in
>>> write back mode, then writing those class files to disk may not cause
>>> them to be actually written to the rotating plates before long after
>>> the process is completed from user perspective.
>>
>> Unless, maybe, the system believes that a file write/delete isn't done
>> until it's physically on the disk and some logs on another... Kind of
>> like some sync-flag was set. (maybe it even is - hardcoded)
> 
> That is how it always was in the old days.
>
AFAIK Unices have traditionally only automatically flushed buffers to 
disk in three circumstances: (1) if they run out of space in RAM, (2) 
when a process terminates all buffers get flushed and (3) output buffers 
are flushed if they haven't been written to for some time and contain 
unflushed data. Apart from that you can, of course, always call fflush() 
whenever the process logic requires, e.g. if a process periodically 
records a restartable checkpoint, it would probably flush buffers for all 
open files as part of recording the checkpoint. Its sometimes necessary, 
too, to flush stdout/stderr if the text is prompting for input read from 
stdin. In general this applies to Linux, and probably also to BSD and 
derivatives.

Other OSen may do things differently, e.g. OS/9, the real-time OS, writes 
blocks as soon as they are complete and when a file is closed, updating 
the file and disk management meta-data at the same time. This is 
deliberate: although it makes i/o a lot slower, its very rare indeed to 
to loose any data or to see a corrupt file in an OS/9 system unless 
you're using a dodgy disk.

Not doing much of the above is a main reason for FAT filing systems to be 
relatively fragile.


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

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

#28097

On 4/15/2014 8:51 AM, Martin Gregorie wrote:
> On Mon, 14 Apr 2014 21:41:50 -0400, Arne Vajhøj wrote:
>
>> On 4/13/2014 6:52 PM, Andreas Leitgeb wrote:
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> If the goal is better performance,
>>>
>>> It's not like I wanted to squeeze another microsecond out of the
>>> compile time, but more like trying to bypass some brake, that the
>>> system has slammed full on for no good reason.
>>>
>>>> But with todays OS/file system caches and disk caches - likely in
>>>> write back mode, then writing those class files to disk may not cause
>>>> them to be actually written to the rotating plates before long after
>>>> the process is completed from user perspective.
>>>
>>> Unless, maybe, the system believes that a file write/delete isn't done
>>> until it's physically on the disk and some logs on another... Kind of
>>> like some sync-flag was set. (maybe it even is - hardcoded)
>>
>> That is how it always was in the old days.
>>
> AFAIK Unices have traditionally only automatically flushed buffers to
> disk in three circumstances: (1) if they run out of space in RAM, (2)
> when a process terminates all buffers get flushed and (3) output buffers
> are flushed if they haven't been written to for some time and contain
> unflushed data.

You are right. Unix never subscribed to the "get the data on the plates"
philosophy.

>               Apart from that you can, of course, always call fflush()
> whenever the process logic requires, e.g. if a process periodically
> records a restartable checkpoint, it would probably flush buffers for all
> open files as part of recording the checkpoint.

AFAIK then fflush only move data from user space to system space.

To get data on the plates you need fsync.


> Other OSen may do things differently, e.g. OS/9, the real-time OS, writes
> blocks as soon as they are complete and when a file is closed, updating
> the file and disk management meta-data at the same time. This is
> deliberate: although it makes i/o a lot slower, its very rare indeed to
> to loose any data or to see a corrupt file in an OS/9 system unless
> you're using a dodgy disk.

Same with VMS.

> Not doing much of the above is a main reason for FAT filing systems to be
> relatively fragile.

Strictly speaking then the multiple flavors of FAT are file system
formats more than file systems. But yes - MS code from around DOS 4 and
onwards has cached data.

Arne

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

#28101

On Tue, 15 Apr 2014 20:00:22 -0400, Arne Vajhøj wrote:

> AFAIK then fflush only move data from user space to system space.
> 
> To get data on the plates you need fsync.
>
The manpages for fflush()m and fsync() could be a little clearer, but I 
read them as saying that both functions force a write to disk. The only 
difference is the type of file reference argument they take: fflush() 
takes a FILE* stream reference while fsync() takes an int file 
description. 

That is pretty much the same as the difference between read() and fread() 
or write() and fwrite().


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

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

#28104

On 04/16/2014 08:29 AM, Martin Gregorie wrote:
> On Tue, 15 Apr 2014 20:00:22 -0400, Arne Vajhøj wrote:
>
>> AFAIK then fflush only move data from user space to system space.
>>
>> To get data on the plates you need fsync.
>>
> The manpages for fflush()m and fsync() could be a little clearer, but I
> read them as saying that both functions force a write to disk. The only
> difference is the type of file reference argument they take: fflush()
> takes a FILE* stream reference while fsync() takes an int file
> description.
>
> That is pretty much the same as the difference between read() and fread()
> or write() and fwrite().
>
>
as an adjunct to the manpages
"The Linux Programming Interface"
13.3 Controlling Kernel Buffering of File I/O
<http://books.google.com/books?id=Ps2SH727eCIC&pg=PA239>

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

#28106

On 04/16/2014 10:58 AM, Jeff Higgins wrote:

> as an adjunct to the manpages
Schedule this. A memento for me.
Kernel Korner - I/O Schedulers - Robert Love
<http://www.linuxjournal.com/article/6931>

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

#28108

On Wed, 16 Apr 2014 12:45:54 -0400, Jeff Higgins wrote:

> On 04/16/2014 10:58 AM, Jeff Higgins wrote:
> 
>> as an adjunct to the manpages
> Schedule this. A memento for me.
> Kernel Korner - I/O Schedulers - Robert Love
> <http://www.linuxjournal.com/article/6931>

Hate to say this, but I was using a a box with a scheduler that was at 
least as good as the Anticipatory Scheduler way back in 1972 on an ICL 
1903S mainframe running the George 3 Mk 6 OS. 

George 3 used a similar directory structure to Unix/Linux. Its i/o 
scheduler was, however, quite a bit different. This maintained two i/o 
queues and a vector for each disk. The vector kept book on where the 
heads were and which direction they were travelling. One of the queues 
held requests for blocks that were 'in front' of the heads and the other 
queue held requests for blocks 'behind' the heads. Both queues were 
sorted. When the 'in front' queue was empty, the queues were swapped and 
the vector reversed, so in practise the heads floated smoothly back and 
forth across the disk while sounding like castenet dancer on speed and 
the i/o rate was much higher than earlier versions, without the i/o 
scheduler, or the manual UDAS executive could manage. 

This was pretty much in the dark ages: these were removable 60 MB, 14 
inch 20 surface 2800 rpm disks with an average 135 mS seek time. Running 
with the manual UDAS executive there was no i/o scheduler, so the heads 
banged randomly back and forth across the disk and you got 8-10 iops/sec 
if you were lucky, while George 3 with it's i/o scheduler could easily 
operate in the 25-35 iops/sec range.


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

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

#28109

On 04/16/2014 03:33 PM, Martin Gregorie wrote:
> On Wed, 16 Apr 2014 12:45:54 -0400, Jeff Higgins wrote:

>> Schedule this. A memento for me.
> Hate to say this,

But I'm glad you did.
Today I first heard of I/O schedulers.
This is why I like following this group.

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

#28110

On 4/16/2014 3:33 PM, Martin Gregorie wrote:
> On Wed, 16 Apr 2014 12:45:54 -0400, Jeff Higgins wrote:
>
>> On 04/16/2014 10:58 AM, Jeff Higgins wrote:
>>
>>> as an adjunct to the manpages
>> Schedule this. A memento for me.
>> Kernel Korner - I/O Schedulers - Robert Love
>> <http://www.linuxjournal.com/article/6931>
>
> Hate to say this, but I was using a a box with a scheduler that was at
> least as good as the Anticipatory Scheduler way back in 1972 on an ICL
> 1903S mainframe running the George 3 Mk 6 OS.
>
> George 3 used a similar directory structure to Unix/Linux. Its i/o
> scheduler was, however, quite a bit different. This maintained two i/o
> queues and a vector for each disk. The vector kept book on where the
> heads were and which direction they were travelling. One of the queues
> held requests for blocks that were 'in front' of the heads and the other
> queue held requests for blocks 'behind' the heads. Both queues were
> sorted. When the 'in front' queue was empty, the queues were swapped and
> the vector reversed, so in practise the heads floated smoothly back and
> forth across the disk while sounding like castenet dancer on speed and
> the i/o rate was much higher than earlier versions, without the i/o
> scheduler, or the manual UDAS executive could manage.
> [...]

     An issue (not necessarily "problem") with this approach is that
the tracks near the inner and outer extremes get fewer/slower accesses
than those near the middle.[*]  That could be turned to advantage,
by allocating frequently-used files in the favored area and relegating
less-used material to the frozen fringes -- but then you're sort of
back in the days of fixed (usually manual) allocations.

     [*] I once heard an instructor explain it this way: He asked us
to think of three friends sitting on a bench, passing a can of beer
back and forth.  Friend A on one end takes a swig and hands the can
to B in the middle, who takes a swig and hands it on to C on the
other end, who takes his swig and hands the can -- to whom?  To his
only neighbor, B.  The swigging sequence is ABCBABCBAB... with B
getting half the beer while A and C split the rest.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web