packager hardcoded addresses

[fmateoc]

Hi all,

At Misys we have recently hit some hardcoded space limits in the packager. We are using VA 7.0
We have modified them in EpRomerImage>>#initializeDefaultSpaces and #initializeSpecialSpaces, and it seems to work, but I am worried that perhaps some of those hardcoded addresses might be "known" by some other code. I know that e.g. there are some other hardcoded addresses/lengths in other places (such as EsImageDumper>>#dumpSegmentHeader or EpImage>>#newSpaceSize) - should we modify those too?
Is there any documentation about the image memory map as the packager/dumper lays it out?

Thank you,

Florin

[wembley]

Florin -

Which addresses did you change and to what values?

[fmateoc]

We modified as follows: we multiplied all lengths by 4, we started from the same lowest startAddress, we preserved contiguity between spaces where it existed, we preserved the gaps between contiguous occupied regions.

OLD VALUE NEW VALUE

FIXEDASSOCS
startAddress: 16r10000000 16r10000000
length: 16r1000000 16r4000000

CLASSES
startAddress: 16r11000000 16r14000000
length: 16r1000000 16r4000000

ROM
startAddress: 16r12000000 16r18000000
length: 16r2000000 16r8000000

CMINFO
startAddress: 16r16000000 16r22000000
length: 16r1000000 16r4000000

FILEPOINTERS
startAddress: 16r17000000 16r26000000
length: 16r1000000 16r4000000

SNAPSHOT
startAddress: 16r18000000 16r2A000000
length: 16r1000000 16r4000000

CODE
startAddress: 16r20000000 16r35000000
length: 16r4000000 16r10000000

RAM
startAddress: 16r28000000 16r49000000
length: 16r2000000 16r8000000


Could you also please explain what is the relationship between EpbMemorySpace(s) and EsMemorySegment(s)? In other words, how does memory allocation happen at image startup, what influences it (I know that we have the the newSpaceSize and oldSpaceSize parameters in abt.ini, but how do they interact with the saved spaces - also, are there any other parameters that influence memory allocation?)

Thank you,

Florin

[tc]

Hello,

At Misys we have recently hit some hardcoded space limits in the packager.

. . . does that mean during packaging, you get a walkback? If so, what does the walkback say?

Also, what is the size of the apps being packaged?

Thanks.

--tc

[fmateoc]

Yes, we got a first walkback, we modified the length for that particular space and then we got a second walkback for a different one, and then we decided to raise the limits for all of them (except the IC-related ones).

We have about 1300 apps and subapps, close to 15,000 classes total, close to 300,000 methods (this is including VA, in a development image).
At runtime, our main runtime image has 12,400 classes

Florin

[fmateoc]

The walkbacks were of the kind:

(space spaceForSize: size) isNil ifTrue: [
self error: space errorString]

[tc]

Hello,

Is it possible to break your app into components and load them as needed? In other words, does the entire app need to sit in memory or can components be loaded based on the selections of the user(s)?

Thanks.

--tc

[fmateoc]

Hi,

This is only software, anything is possible, but it seems much easier to hack those limits.
Unless, of course, you tell us why we shouldn't do it

Florin

[tc]

Hello,

This is only software, anything is possible, but it seems much easier to hack those limits.
Unless, of course, you tell us why we shouldn't do it

. . . those classes look very low level to me and I was not able to find documentation on them. Given that, IMHO, those classes were not intended for end user modification.

--tc

[fmateoc]

Well, sure, that's why I posted in the first place.
But I don't think we can afford to undertake a massive restructuring effort for such fuzzy benefits.

Florin

[fmateoc]

I would also add that eventually you (Instantiations) will have to byte the bullet and take ownership of that code - now that we have 64-bit VMs and huge amounts of memory those limits will look more and more inappropriate

Florin

[tc]

Hello,

With those changes, were you able to package and test your app?

--tc

[fmateoc]

Hi,

Yes, we are using the changes when packaging and everything seems fine

Florin

[tc]

Hello,

Could you open a workspace in an image with your apps loaded and inspect the following code:

Code: Select all

appOC :=OrderedCollection new.
classSet := Set new.
selectorSet := OrderedCollection new.

appOC := SubApplication currentlyLoaded.
appOC do: [ :app |
   classSet addAll: app defined.
   app defined do: [ :cls |
      selectorSet
         addAll: cls selectors;
         addAll: cls class selectors;
         yourself ] ].

Dictionary new
   at: #numberOfApps put: appOC size;
   at: #numberOfClasses put: classSet size;
   at: #numberOfSelectors put: selectorSet size;
   yourself

. . . and post the result?

Thanks.

--tc

[fmateoc]

Here it is:

number of apps: 1299
number of classes: 14877
number of selectors: 334466

Florin