Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-1186040

Oak thread stacks hog more memory than they should

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      1.0alpha
    • CPU:
      sparc
    • OS:
      generic
    • Verification:
      Not verified

      Description

      Oak on Solaris currently mallocs its thread stacks. A user thread stack is 400K by
      default, and Oak tends to have a fair number of user threads going if it's doing
      anything significant. These things being malloced means uses up a lot of brk space.
      It's typically not going to be needed -- thread stacks are normally very small.
      400K was from the days when both the Oak stack and the C stack were in the
      thread stack (and aimed at Oak running the Star7 demo in 4M)!

      On Solaris we should go back to an arrangement where we mmap the stacks from
      /dev/zero, so we only pay for what memory we need. This code had been written for
      the Solaris native threads port, but was backed out: libthread collects dead threads
      with a reaper process that seems to expect the stacks to be there, so I didn't
      seem to be able to free them reliably. The code was never included in the
      reorganized Green system but could be adapted to it.

      Where we have to malloc thread stacks we should consider bringing the default size
      of user thread stacks down. Granted, this is slightly less safe, but our current safety
      comes at a high cost for the average user. If someone really needs larger stacks the
      default can be overridden.

      It would be interesting to know how much thread stack current apps use, and as
      more significant apps are developed how the use grows. That's the sort of info we
      should base our default sizes on.

        Attachments

          Activity

            People

            Assignee:
            tlindholsunw Timothy Lindholm (Inactive)
            Reporter:
            tlindholsunw Timothy Lindholm (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: