Re: Windows 7 and all my Java stuff.

Discussion in 'Java' started by Lew, Nov 25, 2009.

  1. Lew

    Lew Guest

    Thomas Pornin wrote:
    > (**) With PAE, available since the Pentium Pro (that's more than twelve
    > years ago), a 32-bit x86 system may use up to 64 GB of RAM, but not
    > simultaneously: each single process may use only 4 GB.


    I'm aware of no 32b JVM that can specify a heap over about 1.8 GB; most are
    lower. 32b Windows only allows up to 2GB per process or 3GB with a switch.
    The JVM and permanent generation use some of that, leaving less for the heap.

    --
    Lew
     
    Lew, Nov 25, 2009
    #1
    1. Advertising

  2. Lew

    Nigel Wade Guest

    On Wed, 25 Nov 2009 09:19:16 -0500, Lew wrote:

    > Thomas Pornin wrote:
    >> (**) With PAE, available since the Pentium Pro (that's more than twelve
    >> years ago), a 32-bit x86 system may use up to 64 GB of RAM, but not
    >> simultaneously: each single process may use only 4 GB.

    >
    > I'm aware of no 32b JVM that can specify a heap over about 1.8 GB; most
    > are lower. 32b Windows only allows up to 2GB per process or 3GB with a
    > switch. The JVM and permanent generation use some of that, leaving less
    > for the heap.


    $ java -version
    java version "1.6.0_15"
    Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
    Java HotSpot(TM) Server VM (build 14.1-b02, mixed mode)

    $ java -jar -Xmx3700m some.jar
    ....

    $ java -jar -Xmx3800m some.jar
    Error occurred during initialization of VM
    Could not reserve enough space for object heap
    Could not create the Java virtual machine.

    So, the limit on this particular Java application is somewhere between
    3.7GB and 3.8GB of heap.

    I should point out that this is a 32bit JVM running on a 64bit system
    with 32GB of RAM. Nonetheless, the limit on a 32bit application is still
    4GB despite the 64bit OS. What it does mean, though, is that any
    individual application has got a much greater chance of getting the max.
    address space because the entire system isn't limited to 4GB.

    The same may be true of a PAE system, I don't know and can't test it.

    --
    Nigel Wade
     
    Nigel Wade, Nov 25, 2009
    #2
    1. Advertising

  3. Lew

    Lew Guest

    According to Lew :
    >> I'm aware of no 32b JVM that can specify a heap over about 1.8 GB;
    >> most are lower.

    >


    Thomas Pornin wrote:
    > Sun's JVM can. Right now, with Sun's JDK 1.6.0_16, 32-bit version for
    > Linux, I can specify a 3.68 GB heap with '-Xmx3683m', and use it
    > (I made a simple Java code which successfully stored 3683 byte[],
    > each newly allocated of size 1048576, into an ArrayList).
    >
    > The trick here is that while the JDK is a 32-bit binary and runs
    > in a 32-bit system, the Linux kernel itself is a 64-bit kernel. The
    >


    Right to both of you. I should have specified that I meant a 32b JVM
    on a 32b OS. My mistake.

    --
    Lew
     
    Lew, Nov 25, 2009
    #3
  4. Lew

    Nigel Wade Guest

    On Wed, 25 Nov 2009 11:19:21 -0800, Lew wrote:

    > According to Lew :
    >>> I'm aware of no 32b JVM that can specify a heap over about 1.8 GB;
    >>> most are lower.

    >>
    >>

    > Thomas Pornin wrote:
    >> Sun's JVM can. Right now, with Sun's JDK 1.6.0_16, 32-bit version for
    >> Linux, I can specify a 3.68 GB heap with '-Xmx3683m', and use it (I
    >> made a simple Java code which successfully stored 3683 byte[], each
    >> newly allocated of size 1048576, into an ArrayList).
    >>
    >> The trick here is that while the JDK is a 32-bit binary and runs in a
    >> 32-bit system, the Linux kernel itself is a 64-bit kernel. The
    >>
    >>

    > Right to both of you. I should have specified that I meant a 32b JVM on
    > a 32b OS. My mistake.


    Ok, on a 32bit machine:

    $ java -Xmx2700m ParseTime
    Thu Jan 01 08:00:00 GMT 1970
    ....

    $ java -Xmx2800m ParseTime
    Error occurred during initialization of VM
    Could not reserve enough space for object heap
    Could not create the Java virtual machine.

    So, here I'm limited to 2.7GB on a stock openSUSE desktop with 3GB RAM
    and 4GB swap, running:

    $ java -version
    java version "1.6.0_15"

    I thought you used Linux. What distro and memory configuration has
    limited you to 1.8GB?

    --
    Nigel Wade
     
    Nigel Wade, Nov 26, 2009
    #4
  5. Lew

    Lew Guest

    Nigel Wade wrote:
    > Ok, on a 32bit machine:
    >
    > $ java -Xmx2700m ParseTime
    > Thu Jan 01 08:00:00 GMT 1970
    > ...
    >
    > $ java -Xmx2800m ParseTime
    > Error occurred during initialization of VM
    > Could not reserve enough space for object heap
    > Could not create the Java virtual machine.
    >
    > So, here I'm limited to 2.7GB on a stock openSUSE desktop with 3GB RAM
    > and 4GB swap, running:
    >
    > $ java -version
    > java version "1.6.0_15"


    I couldn't be more glad to be proven wrong.

    --
    Lew
     
    Lew, Nov 27, 2009
    #5
  6. Lew

    Nigel Wade Guest

    On Wed, 25 Nov 2009 16:27:18 +0000, DuncanIdaho wrote:

    > Nigel Wade wrote:
    >> On Wed, 25 Nov 2009 09:19:16 -0500, Lew wrote:
    >>
    >>> Thomas Pornin wrote:
    >>>> (**) With PAE, available since the Pentium Pro (that's more than
    >>>> twelve years ago), a 32-bit x86 system may use up to 64 GB of RAM,
    >>>> but not simultaneously: each single process may use only 4 GB.
    >>> I'm aware of no 32b JVM that can specify a heap over about 1.8 GB;
    >>> most are lower.

    >
    > snip
    >
    >> I should point out that this is a 32bit JVM running on a 64bit system
    >> with 32GB of RAM. Nonetheless, the limit on a 32bit application is
    >> still 4GB despite the 64bit OS. What it does mean, though, is that any
    >> individual application has got a much greater chance of getting the
    >> max. address space because the entire system isn't limited to 4GB.
    >>
    >> The same may be true of a PAE system, I don't know and can't test it.
    >>
    >>

    > OK well I've ordered my new laptop with Windows 7
    >
    > By the way http://java.sun.com/javase/downloads/widget/jdk6.jsp offers
    > JDK 6 Update 17 for Windows and Windows x64 where the archive for the 64
    > bit version is smaller than that for the 32 bit version by around 8MB,
    > interesting huh,


    Well, the Linux 64bit version is about 1MB larger. It doesn't really tell
    you anything about the unpacked size, or the size of running JVM.

    > also, apparently the 64 bit release can be used in 32
    > bit mode...


    Maybe, maybe not:

    $ /usr/java/jdk1.6.0_17/bin/java -version
    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)

    $ /usr/java/jdk1.6.0_17/bin/java -version -d32
    Running a 32-bit JVM is not supported on this platform.

    I don't know whether it works on Windows.

    >
    > Anyway, it will be interesting to see just how big the heap can be with
    > a 64bit JVM running on a 64bit system. Roll on delivery day.
    >


    Whatever the limit of your VM is, presumably. Probably RAM+swap, or the
    administrator/OS defined per-process VM limit. You can request max. heap
    size much more than the available VM, but it's not actually physically
    allocated until required, for example:

    $ /usr/java/jdk1.6.0_17/bin/java -Xmx128000m -jar some.jar

    works on a system with only 32GB RAM.

    If, however, I restrict the per-process VM to 20GB using:

    $ ulimit -v 20000000

    I get:

    $ /usr/java/jdk1.6.0_17/bin/java -Xmx20000m -jar dist/MP3FileCopier.jar .
    Error occurred during initialization of VM
    Could not reserve enough space for object heap
    Could not create the Java virtual machine.

    but I can request 19GB.

    As I said elsethread, taking up a few MB of extra space for 64bit
    addresses is not something to be overly concerned about.

    --
    Nigel Wade
     
    Nigel Wade, Nov 27, 2009
    #6
  7. On 25-11-2009 09:19, Lew wrote:
    > Thomas Pornin wrote:
    >> (**) With PAE, available since the Pentium Pro (that's more than twelve
    >> years ago), a 32-bit x86 system may use up to 64 GB of RAM, but not
    >> simultaneously: each single process may use only 4 GB.

    >
    > I'm aware of no 32b JVM that can specify a heap over about 1.8 GB; most
    > are lower. 32b Windows only allows up to 2GB per process or 3GB with a
    > switch. The JVM and permanent generation use some of that, leaving less
    > for the heap.


    Besides the already mentioned case of 32 bit JVM on 64 bit OS,
    then JRockit is said to be able to use the /3GB in Windows.

    I think I have been told that 32 bit Solaris also allows
    the JVM to go above the approx. 1.8 GB.

    Arne
     
    Arne Vajhøj, Jan 4, 2010
    #7
  8. On 25-11-2009 10:13, Nigel Wade wrote:
    > I should point out that this is a 32bit JVM running on a 64bit system
    > with 32GB of RAM. Nonetheless, the limit on a 32bit application is still
    > 4GB despite the 64bit OS. What it does mean, though, is that any
    > individual application has got a much greater chance of getting the max.
    > address space because the entire system isn't limited to 4GB.
    >
    > The same may be true of a PAE system, I don't know and can't test it.


    PAE increases physical address space not virtual address space,
    so it should not make a difference.

    Arne
     
    Arne Vajhøj, Jan 4, 2010
    #8
  9. On 25-11-2009 15:00, Peter Duniho wrote:
    > DuncanIdaho wrote:
    >> [...]
    >> Anyway, it will be interesting to see just how big the heap can be
    >> with a 64bit JVM running on a 64bit system. Roll on delivery day.

    >
    > It will probably depend on the OS. But, for Windows and based on this
    > MSDN article (http://support.microsoft.com/default.aspx?scid=889654), I
    > would expect your 64-bit JVM process to max out at 8 terabytes (or just
    > under), the maximum virtual address space for a 64-bit process on Windows.


    Note that it is a Windows limitation.

    The processors support 256 TB.

    > It's interesting to note that 64-bit Windows has essentially the same
    > "half and half" virtual address space approach 32-bit Windows does. It's
    > just that the numbers are bigger (16TB virtual address space, where 8TB
    > is dedicated to the application).


    Cutler took that design with him from DEC.

    > Anyway, with a theoretical 8TB limit on application allocations, unless
    > you have some really huge disk or RAID volume, you'll run out of disk
    > space before you can hit the actual theoretical limit. That is, observed
    > behavior will be configuration-dependent. (But that's just for
    > Windows...my understanding is that with most versions of Linux, for
    > example, it will happily allow you to allocate as much memory is
    > theoretically possible for the process, and only fail due to lack of
    > system resources if your process actually tries to use the allocated
    > memory).


    Note even though Windows does not allow overcommit like *nix and VMS
    does, then the restriction is not:
    sum of virtual space <= size pagefile
    but:
    sum of virtual space <= size pagefile + size RAM + size memory mapped
    files

    In practice size RAM would be so much smaller than size of disks
    that the bottom line is the smae.

    Arne
     
    Arne Vajhøj, Jan 4, 2010
    #9
  10. Lew

    Roedy Green Guest

    On Sun, 03 Jan 2010 22:25:00 -0500, Arne Vajhøj <>
    wrote, quoted or indirectly quoted someone who said :

    >
    >The processors support 256 TB.


    The architecture may, but surely no chips on the market now have the
    addressing pins to support that.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim.
    ~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)
     
    Roedy Green, Jan 6, 2010
    #10
  11. Lew

    Arne Vajhøj Guest

    On 06-01-2010 15:39, Roedy Green wrote:
    > On Sun, 03 Jan 2010 22:25:00 -0500, Arne Vajhøj<>
    >> The processors support 256 TB.

    >
    > The architecture may, but surely no chips on the market now have the
    > addressing pins to support that.


    Actually they do.

    Arne
     
    Arne Vajhøj, Jan 7, 2010
    #11
  12. Lew

    Roedy Green Guest

    On Wed, 06 Jan 2010 22:28:28 -0500, Arne Vajhøj <>
    wrote, quoted or indirectly quoted someone who said :

    >>
    >> The architecture may, but surely no chips on the market now have the
    >> addressing pins to support that.

    >
    >Actually they do.


    Future shock. The biggest Asus MB I could find supports 24 GB, so I
    guess even if the chips have the full 64 bit complement of addressing
    lines, the motherboards only support something like 35 of them. I
    wonder who has machines that need the high order lines. Maybe
    somewhere out there are i/o devices that look like real ram to a CPU
    but which manage virtual ram with a multilayers of cache, including
    flash RAM, and high speed disks.

    I wonder how long before mass-storage and virtual RAM are unified so
    that mass storage is accessed as a dedicated part of virtual RAM.


    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim.
    ~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)
     
    Roedy Green, Jan 7, 2010
    #12
  13. Lew

    Eric Sosman Guest

    On 1/6/2010 11:57 PM, Roedy Green wrote:
    >
    > I wonder how long before mass-storage and virtual RAM are unified so
    > that mass storage is accessed as a dedicated part of virtual RAM.


    It'll take another minus twenty-two to minus forty-six
    years, I'd guess.

    http://en.wikipedia.org/wiki/Single_level_store

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 7, 2010
    #13
  14. Lew

    Roedy Green Guest

    On Wed, 06 Jan 2010 21:09:49 -0800, Peter Duniho
    <> wrote, quoted or indirectly quoted
    someone who said :

    >> I wonder how long before mass-storage and virtual RAM are unified so
    >> that mass storage is accessed as a dedicated part of virtual RAM.

    >
    >You've been able to do that for years. It's called memory-mapped files.


    That is not what I mean. I mean at a hardware level, that the
    hardware CPU (not the application program) sees as what it thinks is
    245TB bank of RAM. However the RAM "chips" fake this with a firmware
    managed virtual RAM system of several layers of cache, perhaps even at
    the lowest level accessing the net.

    The idea is special purpose and proprietary hardware can go inside the
    "RAM". It would allow even the clutziest OS to evolve rapidly to the
    cleverest virtual RAM system.

    The "RAM" would have to warn the CPU when it was going to take a long
    time to satisfy a request, or the CPU might be so heavily
    hyperthreaded it would not matter if most of the threads were waiting
    on RAM.

    It seems to me if it is possible to carve out any well-understood
    chunk of functionality, and put in inside a peripheral, that should
    encourage innovation through unusual proprietary, hardware-assisted
    techniques, while simplifying the OS, and making it less vulnerable to
    failure or attack.

    Ideas along that line include the multi-line serial controller
    (available since the DOS days), in-disk cache firmware (standard now),
    the martha, an SQL appliance and the dark room.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim.
    ~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)
     
    Roedy Green, Jan 7, 2010
    #14
  15. On Thu, 07 Jan 2010 06:19:29 -0800, Roedy Green wrote:

    > On Wed, 06 Jan 2010 21:09:49 -0800, Peter Duniho
    > <> wrote, quoted or indirectly quoted
    > someone who said :
    >
    >>> I wonder how long before mass-storage and virtual RAM are unified so
    >>> that mass storage is accessed as a dedicated part of virtual RAM.

    >>
    >>You've been able to do that for years. It's called memory-mapped files.

    >
    > That is not what I mean. I mean at a hardware level, that the hardware
    > CPU (not the application program) sees as what it thinks is 245TB bank
    > of RAM. However the RAM "chips" fake this with a firmware managed
    > virtual RAM system of several layers of cache, perhaps even at the
    > lowest level accessing the net.
    >

    This was done years ago - around 1970 to be precise and was known as the
    IBM Future Series.

    The architecture was very different to the System/360 /370 mainframes and
    it was canned because IBM chickened out over forcing their customer base
    to migrating to something so radical: a huge amount of S/360 code was
    written in assembler and/or used the IMS hierarchic database but Future
    Series had no assembler (it was a PL/1 machine in the same way that
    Unices run on C machines) and didn't support IMS.

    However, the idea was good. It not only worked, but worked well and was
    revived in the late 80s as the System/38. The second generation S/38 was
    better known as the AS/400 and the various names the sales droids called
    it more recently.

    At a user and programming level you had files and libraries, but that was
    only an implementation of the usual programing environment. Without it
    programming in C. PL/I, COBOL and even RPG would have been hard because
    virtually all programming languages except SQL expect to deal with files.

    However, beneath that abstraction layer there was a single, flat storage
    system that mapped virtual memory onto RAID 5 disks handled by good, fast
    parallel tasking disk controllers. The downside was that you had
    absolutely no control over the placement of the blocks making up a file.
    The OS/400 load balancing algorithm took care of that. The upsides were
    that all data was on redundant, hot-pluggable disks, random access
    performance was good and serial access to a file was blindingly fast
    thanks to the ability of controllers to stream in parallel off all the
    disks in a RAID 5 set.

    > The idea is special purpose and proprietary hardware can go inside the
    > "RAM". It would allow even the clutziest OS to evolve rapidly to the
    > cleverest virtual RAM system.
    >

    As I said, its been done. See above. Actually, under the covers the
    AS/400 was a SNA LU6.2 network with processors, disk controllers, network
    controllers, implemented as nodes strung on the network.

    > The "RAM" would have to warn the CPU when it was going to take a long
    > time to satisfy a request, or the CPU might be so heavily hyperthreaded
    > it would not matter if most of the threads were waiting on RAM.
    >

    Didn't appear to be an issue, but then every process ran in its own VM
    and the process scheduler was pretty good.

    > It seems to me if it is possible to carve out any well-understood chunk
    > of functionality, and put in inside a peripheral, that should encourage
    > innovation through unusual proprietary, hardware-assisted techniques,
    > while simplifying the OS, and making it less vulnerable to failure or
    > attack.
    >

    Exactly so. The key is organising the system as a network of intelligent
    nodes. Other cases worth looking at as ways of using this architecture
    are the ICL System/39 and HP's Guardian NonStop fault tolerant computers.
    Its worth pointing out, too, that any Unix based on a Mach kernel is
    built on the same principle, though here all the nodes and the network
    are inside the same chunk of RAM.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Jan 7, 2010
    #15
  16. On Thu, 07 Jan 2010 08:56:10 -0500, Eric Sosman wrote:

    > On 1/6/2010 11:57 PM, Roedy Green wrote:
    >>
    >> I wonder how long before mass-storage and virtual RAM are unified so
    >> that mass storage is accessed as a dedicated part of virtual RAM.

    >
    > It'll take another minus twenty-two to minus forty-six
    > years, I'd guess.
    >
    > http://en.wikipedia.org/wiki/Single_level_store
    >

    That is OK except that it left out IBM's first iteration, Future Series,
    which was canned (see my previous post) around 1970. As this range was
    never publicly announced, I guess it isn't generally known but it was
    canned just before the S/370s (the first virtual memory IBM mainframes)
    appeared.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Jan 7, 2010
    #16
  17. Lew

    Roedy Green Guest

    On Thu, 07 Jan 2010 06:32:30 -0800, Patricia Shanahan <>
    wrote, quoted or indirectly quoted someone who said :

    >What advantage do you see to managing this from firmware rather than
    >operating system software, as is done in current implementations of
    >memory-mapped files?


    1. It can be hardware assisted. Imagine if virtual RAM were done
    entirely with software!

    2. It can use proprietary techniques even in an open source OS.

    3. Innovation can be used immediately. You don't have to wait for the
    OS people to implement it.

    4. machines are more modular. If you need more performance, you just
    plug in higher performance peripherals. The OS does not need to impose
    complexity and cost on those who don't need it.

    5. The OS is simpler.

    6. Malfunctioning of the something in one of these smart peripherals
    can harm only itself. It cannot reach out and screw up unrelated
    software.

    7. By allowing vendors to specialise, they can be smaller and more
    numerous. They should be thus more competition and evolution.

    8. It is much like the advantage of having a high level standard video
    driver interface rather than having the OS work directly with the
    video iron.

    >
    >Hardware and firmware are less flexible and harder to update than the
    >operating system. Hard wired decisions have to be kept simple.
    >Performance is the usual reason for moving memory hierarchy layer
    >management into hardware or firmware, despite those disadvantages. That
    >does not apply to the disk layer, given disk access times and block sizes.


    It theory that is correct, but when you have only one vendor in effect
    for your OS, if they screw up, you are screwed. What I am hoping to
    do is carve away chunks of the OS and parcel it out to multiple
    implementors. The smart peripherals presumably would firmware in it,
    that with proper design should be no harder to update than software,
    but could be designed to prevent tampering by anyone but the hardware
    maker. E.g. updates need to be digitally signed.




    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim.
    ~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)
     
    Roedy Green, Jan 7, 2010
    #17
  18. Lew

    Roedy Green Guest

    On Thu, 7 Jan 2010 18:06:19 +0000 (UTC), Martin Gregorie
    <> wrote, quoted or indirectly quoted
    someone who said :

    >>

    >As I said, its been done.


    That is about half way to what I am proposing. The System 38 had what
    amounted to a gigantic virtual RAM system with 128-bit addressing. The
    CPU was completely "aware" of what was in real RAM and what was not.

    I am floating the idea that the CPU not know that. The CPU HARDWARE
    (not just the software) would think it has terabytes of real silicon
    RAM. The RAM chips themselves manage the virtualness with layers of
    cache of varying speed working down to disk and the internet. The RAM
    "chips" are a miniature proprietary computer", in the simplest case
    implemented with pure hardware with static ram cache and real RAM.

    To the programmer, the machine would look much like a System 38 with a
    blending of RAM for running and the file system into a single flat
    address space.

    RAM would be a bit smarter than now. It would have commands to
    forget ranges of bytes, clear ranges of bytes, and copy ranges of
    bytes.The RAM peripheral would be free to transparently implement
    these operations with lazy logic. The peripheral could be in the
    background defragging its various layers.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim.
    ~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)
     
    Roedy Green, Jan 7, 2010
    #18
  19. Lew

    Roedy Green Guest

    On Thu, 7 Jan 2010 18:06:19 +0000 (UTC), Martin Gregorie
    <> wrote, quoted or indirectly quoted
    someone who said :

    >> The "RAM" would have to warn the CPU when it was going to take a long
    >> time to satisfy a request, or the CPU might be so heavily hyperthreaded
    >> it would not matter if most of the threads were waiting on RAM.
    >>

    >Didn't appear to be an issue, but then every process ran in its own VM
    >and the process scheduler was pretty good.


    The System 38 had no problem that way because whenever it accessed
    virtual RAM not in real ram the virtual RAM hardware would trigger and
    interrupt. The OS would look in its tables, schedule a read of the
    missing page. When it arrived it flushed it translation lookaside
    buffers and modified the lookup tables, and restart the stalled task.

    In the system I am proposing, the response from the RAM peripheral
    could be from sub nanoseconds to seconds. If it were going to be a
    long time, the CPU would probably want to know so it could get on with
    some other task, rather than waiting.

    If you had enough hardware hyperthreads to give one to every running
    thread, (I am talking a bit in to the future here. Computing seems to
    advance primarily by figuring out new ways to waste once scarce
    resources.) then you might not bother.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim.
    ~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)
     
    Roedy Green, Jan 7, 2010
    #19
  20. Lew

    Roedy Green Guest

    On Thu, 7 Jan 2010 18:12:36 +0000 (UTC), Martin Gregorie
    <> wrote, quoted or indirectly quoted
    someone who said :

    >That is OK except that it left out IBM's first iteration, Future Series,
    >which was canned (see my previous post) around 1970. As this range was
    >never publicly announced, I guess it isn't generally known but it was
    >canned just before the S/370s (the first virtual memory IBM mainframes)
    >appeared.


    Thinking back to the days of the IBM 360/370 MFT/MVT we had streams of
    batch jobs for 70K, 149K, and 210K.

    Most commercial jobs written in PL/1 fit in 70k.
    A big FORTRAN job was 210K.

    Today with Jet, the smallest Java apps are about 60K.

    The smallest useful Java app jar is about 15K.

    However, java.exe typically runs with about 128 MEGABYTES for the
    heap, and that is not counting the room for java.exe, DLL native code
    and classes.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim.
    ~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)
     
    Roedy Green, Jan 7, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Girish
    Replies:
    3
    Views:
    423
    Girish
    Feb 24, 2004
  2. gamehack
    Replies:
    3
    Views:
    586
    gamehack
    Dec 23, 2005
  3. Roedy Green

    Re: Windows 7 and all my Java stuff.

    Roedy Green, Nov 22, 2009, in forum: Java
    Replies:
    3
    Views:
    360
    Steve Sobol
    Nov 23, 2009
  4. Roedy Green

    Re: Windows 7 and all my Java stuff.

    Roedy Green, Nov 23, 2009, in forum: Java
    Replies:
    4
    Views:
    361
    Arved Sandstrom
    Nov 24, 2009
  5. John Locke
    Replies:
    4
    Views:
    144
    Shailendra Kamath
    Aug 9, 2008
Loading...

Share This Page