Does "fixed space" grow?

• The increment of growth (memory segment size) is specified on the command line (-mf) or in the .INI file (fixedSpaceSize)
• An object that is to be made fixed must fit within one fixed memory segment, so it can be no larger than fixedSpaceSize
• The documentation for fixedSpaceSize and -mf is incorrect since it describes the old (no growth) fixed space support (will be fixed in 8.6.1 documentation)

John

On Thursday, August 22, 2013 6:52:51 AM UTC-4, dswartz wrote:

Hello Richard,

Fixed space doesn't grow. "There is no more fixed space available."
means contiguous memory could not be found within the fixed space
to allocate the object. Note that there may be unused memory in fixed
space, just not enough contiguous unused memory for the object you are
trying to put there.

You can think of fixed space as "fixed" in two ways: 1. The size of
the space is fixed at image startup. 2. The objects
in fixed space are "fixed" in place. They do not move and do not
participate in automatic garbage collection. They don't move or get
automatically GC'd because the OS calls you make, passing them as an
argument, expect them to stay at the same address. Since OS calls can
be asynchronous, the GC doesn't dare touch them. Thus, fixed space is
subject to fragmentation as well as simply running out of space.

Doug Swartz


Wednesday, August 21, 2013, 6:00:08 PM, you wrote:

> In the Programmer's Reference manual, under VA Smalltalk Virtual
> Machine API: Asynchronous callouts: Managing resources,
> one of the listed resource limitations is "There is no more fixed space available."

> Is this an error that would arise because free space doesn't grow
> or is it an error that would only arise if you had effectively
> exhausted available memory and it couldn't any longer grow?

• Available memory is exhausted
• The object that is being fixed is large than a single fixed space memory segment

In the Programmer's Reference manual, under VA Smalltalk Virtual Machine API : Asynchronous callouts : Managing resources,
one of the listed resource limitations is "There is no more fixed space available."

Is this an error that would arise because free space doesn't grow or is it an error that would only arise if you had effectively exhausted available memory and it couldn't any longer grow?

Richard -

 

There are 2 possibilities:

• Available memory is exhausted
• The object that is being fixed is large than a single fixed space memory segment

I will see that this situation is more fully described in the documentation for 8.6.1.

 

John

On Wednesday, August 21, 2013 7:00:08 PM UTC-4, Richard Sargent wrote:

In the Programmer's Reference manual, under VA Smalltalk Virtual Machine API : Asynchronous callouts : Managing resources,
one of the listed resource limitations is "There is no more fixed space available."

Is this an error that would arise because free space doesn't grow or is it an error that would only arise if you had effectively exhausted available memory and it couldn't any longer grow?

• In a development image, the initial size of fixed space is whatever the size of fixed space was when the image was saved
• In a runtime image, the initial size is the size of fixed space as determined by the packager when the image was created + 1024 bytes

On Friday, September 6, 2013 12:44:38 PM UTC-4, Richard Sargent wrote:

Thanks for the information, John.

In the absence of any command line parameter or INI file entry, what value is used (or how would one determine that value?) for the segment size / growth factor? I ask because in my initial tests, I had only the default set and I could not allocate a somewhat large object in fixed space. ("somewhat large" means 256 KB, not exactly huge) There was plenty of available OS memory. Testing with a parameter of 16 MB never exercised the growth functionality, so it appeared to me as if there was no automatic growth functionality.


I understand you are busy with ESUG, so there is no particular rush on the answers. But please do elaborate in the 8.6.1 documentation.

By the way, I found accessing a byte structure in fixed space was about 10% faster than accessing the equivalent structure allocated in OS memory. Does that agree with your expectation? Such a performance benefit might be worthwhile if fixed memory is easy to use (and grows automatically), but would be a pain for users and our support otherwise. :-)


Thanks,
Richard

On Friday, September 6, 2013 7:14:30 AM UTC-7, John O'Keefe wrote:

Richard -

 

There are 2 possibilities:

• Available memory is exhausted
• The object that is being fixed is large than a single fixed space memory segment

I will see that this situation is more fully described in the documentation for 8.6.1.

 

John

On Wednesday, August 21, 2013 7:00:08 PM UTC-4, Richard Sargent wrote:

In the Programmer's Reference manual, under VA Smalltalk Virtual Machine API : Asynchronous callouts : Managing resources,
one of the listed resource limitations is "There is no more fixed space available."

Is this an error that would arise because free space doesn't grow or is it an error that would only arise if you had effectively exhausted available memory and it couldn't any longer grow?