Loading ...
Sorry, an error occurred while loading the content.
 

When does the GC kick in?

Expand Messages
  • Victor B. Putz
    Still flailing around with SE -0.77 and the PalmOS (I ll upgrade to a higher version someday!), and discovered in one of my programs that I was running out of
    Message 1 of 6 , Aug 1, 2001
      Still flailing around with SE -0.77 and the PalmOS (I'll upgrade to a
      higher version someday!), and discovered in one of my programs that I was
      running out of memory, generating nasty errors etc. If I periodically
      forced garbage collection using full_collect, the problem went away.

      So I'm wondering--when is garbage collection initiated? Since the PalmOS
      (at least around version 3.1; later versions give more memory) only allows
      about 30k for the program's dynamic allocation, this goes away quickly.
      Is there any way to get the GC to "automatically" trigger earlier?

      Just curious...

      -->VPutz
    • Marcio Marchini
      Take a look at the messages for thread Is the GC really GC ing ? http://groups.yahoo.com/group/smalleiffel/message/2562 and also the messages for thread GC
      Message 2 of 6 , Aug 1, 2001
        Take a look at the messages for thread "Is the GC really GC'ing ?"

        http://groups.yahoo.com/group/smalleiffel/message/2562


        and also the messages for thread "GC question (upper limit on memory use ?)
        "

        http://groups.yahoo.com/group/smalleiffel/message/2525



        What I have seen in another OO system in the past is a call to the GC in
        the object allocator (routine that allocates RAM for new objects). SE does
        not seem to do this.

        I suspect you want to do memory allocation like the PocketSmalltalk VM
        does, to go beyond this small memory limit.


        marcio


        > -----Original Message-----
        > From: Victor B. Putz [mailto:vputz@...]
        > Sent: August 1, 2001 8:00 AM
        > To: smalleiffel@...
        > Subject: When does the GC kick in?
        >
        >
        >
        > Still flailing around with SE -0.77 and the PalmOS (I'll upgrade to a
        > higher version someday!), and discovered in one of my programs that I was
        > running out of memory, generating nasty errors etc. If I periodically
        > forced garbage collection using full_collect, the problem went away.
        >
        > So I'm wondering--when is garbage collection initiated? Since the PalmOS
        > (at least around version 3.1; later versions give more memory) only allows
        > about 30k for the program's dynamic allocation, this goes away quickly.
        > Is there any way to get the GC to "automatically" trigger earlier?
        >
        > Just curious...
        >
        > -->VPutz
        >
        >
        >
        >
      • Berend de Boer
        ... AFAIK it is only triggered at about 10MB. Limit should be somewhere in the SmallEifel sources. -- Groetjes, Berend. (-:
        Message 3 of 6 , Aug 1, 2001
          "Victor B. Putz" <vputz@...> writes:

          > So I'm wondering--when is garbage collection initiated? Since the PalmOS
          > (at least around version 3.1; later versions give more memory) only allows
          > about 30k for the program's dynamic allocation, this goes away quickly.
          > Is there any way to get the GC to "automatically" trigger earlier?

          AFAIK it is only triggered at about 10MB. Limit should be somewhere in
          the SmallEifel sources.

          --
          Groetjes,

          Berend. (-:
        • Victor B. Putz
          ... Ack... not an encouraging set of messages, I must say (and I think some of it refers to newer versions of SE than I am using (-0.77); for example, there is
          Message 4 of 6 , Aug 2, 2001
            On Wed, 1 Aug 2001, Marcio Marchini wrote:

            > Take a look at the messages for thread "Is the GC really GC'ing ?"
            > and also the messages for thread "GC question (upper limit on memory use ?)
            > "
            > What I have seen in another OO system in the past is a call to the GC in
            > the object allocator (routine that allocates RAM for new objects). SE does
            > not seem to do this.

            Ack... not an encouraging set of messages, I must say (and I think some of
            it refers to newer versions of SE than I am using (-0.77); for example,
            there is no se_malloc anywhere to be seen).

            On the other hand, version -0.77 does use malloc/calloc/realloc quite
            liberally, which in the case of ePalm are simply #defines which map to
            MemPtrNew and friends in the PalmOS. So mapping them to my own
            allocation functions which check for space remaining and call gc_start
            should work okay... I think (grin).

            > I suspect you want to do memory allocation like the PocketSmalltalk VM
            > does, to go beyond this small memory limit.

            Are you referring to the line that the PocketST VM uses database memory
            for object memory to give you the full addressable memory of the device?
            According to the authors, this is actually *not* true; the additional
            overhead of the database memory access made using database memory
            prohibitive, so sadly the PocketST VM has the same amount of memory
            available as any other Palm product. I thought about trying to hack SE's
            garbage collector to use database memory... but I really am trying to make
            a modified *runtime* without changing the source of SE.

            I'm not sure when I'm going to update the product to later versions of SE
            than -0.77... I'm still in the stages where adding more functionality to
            the PalmOS library is more important than bringing the thing up to date
            with SE... the ACE support in -0.75 is pretty compelling, though, since it
            might allow me to turn on selective assertion checks and keep the size of
            the code low enough that this is feasible. Currently an application
            generated without -boost contains too much information for the poor little
            PalmOS development kit to deal with...

            On the other hand, maybe I'll wait for agents (heh).

            Can anyone tell me if the generated GC code for objects (the gc_markXX,
            gc_sweepXX, gc_align_markXX, and newXX) is smaller between -0.77 and
            -0.75? I ask because right now the GC code winds up being about half of
            the executable program size, which has bumped me up against a couple of
            limits a few times (right now I break up the GC code into two "segments"
            for the PalmOS, with gc_mark and gc_sweep functions in one segment and
            gc_align_mark and new functions in a second one, which works great for
            now).

            -->VPutz
          • Victor B. Putz
            On Thu, 2 Aug 2001, Marcio Marchini wrote: [PocketSmallTalk not using storage memory] ... No, I trusted Eric Arseneau s message in the PocketStug message board
            Message 5 of 6 , Aug 2, 2001
              On Thu, 2 Aug 2001, Marcio Marchini wrote:

              [PocketSmallTalk not using storage memory]
              > Didn't know that. Did you double-check the sources for the VM ?

              No, I trusted Eric Arseneau's message in the PocketStug message board
              back in April:

              http://groups.yahoo.com/group/pocketstug/message/1262

              > Is the VM bundled with each Pocket ST app or is it shared (which means you
              > can have say 10 different PST apps installed and just 1 VM, therefore with
              > only 1 copy of the GC code, method dispatcher, etc) ?

              Bundled, same as an ePalm-generated executable

              > You will notice that usually VMs have all this code and they can run your
              > many apps. You only have 1 copy of the GC in the system, shared.

              This is true for the most part. On the other hand, I somewhat like having
              everything packed into the executable. In SmallEiffel, though, the point
              is somewhat moot because each *class* has its own mark/sweep/new functions
              which are generated--so the more classes, the more GC code is generated
              (it's almost as if each class has its own wee GC, which must be nice for
              optimization but does generate a fair amount of code).

              Basically, the GC is so much of the generated code that bundling the GC
              code into its own 32k section still overflowed section boundaries... so
              now all the mark functions go into a segment, all the sweep functions go
              into a segment, etc. This *should* last me a good long time and seems to
              be working OK.

              > For the PC it is a different story. Every time you launch a VM (java,
              > Smalltalk, etc) you get a full copy of the GC, class files, etc etc. Very
              > far from being shared across apps like low-level DLLs.

              True... but you'd have to have some seriously good versioning information
              to support VMs in DLL form. You're right, .net may help some of this, but
              I am extremely worried about .NET on non-MS platforms...

              -->VPutz
            • Marcio Marchini
              ... yes ... Didn t know that. Did you double-check the sources for the VM ? Is the VM bundled with each Pocket ST app or is it shared (which means you can have
              Message 6 of 6 , Aug 2, 2001
                > Are you referring to the line that the PocketST VM uses database memory
                > for object memory to give you the full addressable memory of the device?

                yes

                > According to the authors, this is actually *not* true; the additional
                > overhead of the database memory access made using database memory
                > prohibitive, so sadly the PocketST VM has the same amount of memory
                > available as any other Palm product.


                Didn't know that. Did you double-check the sources for the VM ?

                Is the VM bundled with each Pocket ST app or is it shared (which means you
                can have say 10 different PST apps installed and just 1 VM, therefore with
                only 1 copy of the GC code, method dispatcher, etc) ?


                > I ask because right now the GC code winds up being about half of
                > the executable program size, which has bumped me up against a couple of
                > limits a few times


                Another problem of making each executable have a full copy of GC, method
                dispatcher, etc etc. I made a comment related to this on the elj list, see
                http://groups.yahoo.com/group/elj-win32-dev/message/963

                You will notice that usually VMs have all this code and they can run your
                many apps. You only have 1 copy of the GC in the system, shared. One of the
                Java VMs for the Pilot works like this. I am not sure if PocketSmalltalk can
                work this way or not, that's why I asked.

                For the PC it is a different story. Every time you launch a VM (java,
                Smalltalk, etc) you get a full copy of the GC, class files, etc etc. Very
                far from being shared across apps like low-level DLLs.

                Again, I do hope that a Universal VM like .NET will free language people
                from the plumbing business (GC, method dispatcher, etc) and we'll have a
                more consistent story, and more sharing. Your PDA will come with the UVM,
                and you just generate code for it.


                marcio
              Your message has been successfully submitted and would be delivered to recipients shortly.