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

Groups > comp.lang.java.programmer > #28111

Re: compile directly into a .zip/.jar file?

Show key headers only | View raw

On Wed, 16 Apr 2014 16:20:19 -0400, Eric Sosman wrote:

> 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.
>
I'm certain you're right, but I don't remember ever hearing how George 
placed files in its filestore so can't add anything about its file 
allocation strategy.

I know that files moved. This was back in the days when disk was scarce 
and expensive, so its disk usage strategy reflected that: 

- it did automatic incremental backups at configurable intervals to
  magnetic tape. You could do 1-3 copies in parallel.

- if it was getting short of disk space, the Backing Store Unjammer
  started up. This freed up space by erasing the online copies of the
  largest files that had not been accessed for the longest time and 
  which had offline backups until it had freed sufficient space.

- if a user or batch job needed a file that had been thrown offline,
  it automatically asked the operator to put a tape containing it online
  and copied the file back to disk. Its scripting language also allowed
  a user or batch job to issue retrieves ahead of time for all the files
  that would be needed.

A couple of other of George's features that may give you some useful 
ideas are:

Separating error handlers from main line code
---------------------------------------------
George was written in chapters: each was a small, relocatable block of 
code that carried out a single task. Early on it was realised that George 
would run faster if very OS task was split in two: one chapter contained 
the error-free path and the other contained error handling code. This 
added speed because the error handlers are generally used infrequently 
and so it didn't matter if the error handlers were slow. Meanwhile, the 
limited memory[*] could keep many more frequently used chapters in memory 
if their error handling code was left on disk until needed. This may also 
work with modern paging systems.

* 1900s used a fixed length instruction set. Each 24 bit word could hold 
one instruction or four 6-bit characters. Our 1903S had 32 Kwords (128 
Kchars) of memory which allowed us to support 4-6 online users, a 
background job, spooled input (cards or paper tape) and printed output.
It had a 3.6 uS clock cycle but, despite this, handled its KSR33 teletypes 
smartly enough that you weren't concious of it being slow.

Minimising unwanted trace logging
---------------------------------
The guts of George is where my favourite way of minimising debug traces 
came from: instead of logging everything, you write tracing into a 
circular buffer and, if an error occurs, you dump the buffer before 
outputting the error and stopping. You size the buffer to suit the amount 
of trace lines you need to localise the problem - generally 50-100 trace 
lines is enough. This works really well for long-running processes that 
only occasionally mess up because you don't end up with several megabytes 
of tracing to search through when you're trying to find the interesting 
bits and their causes. 

Needless to say, my ReportError Java class has this implemented as an 
optional tracing facility.


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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web