Asynchronous call-outs and parameter passing ...

[marten]

Reading the documentation:

Because objects are copied during an asynchronous call, the parameters passed to the function should not be used while the asynchronous call is in progress. The contents of the parameters may be changed at any time by the asynchronous call.

is this also true for static future calls or resource future calls ? What exactly means "objects are copied" ?

Does it mean, that if I pass a 2 meg ByteArray to that routine, it is copied internally ... ????

Marten

[wembley]

Marten -

A little further up the page that you quoted from this is explained.

Objects located in movable memory that are passed into an asynchronous call are copied into a location in non-movable memory for the duration of the asynchronous call. When the asynchronous call completes, the arguments are copied back to the original objects. If the object is not copied, the garbage collector may move the object during the call, resulting in unpredictable behavior.

So the answer is yes, all objects that are passed out to asynchronous calls of any sort are copied to FixedSpace.

[vincid]

Hi John,

Is there any way to force objects into fixed space without causing problems with garbage collection? You mentioned this for parameter passing:

Marten -
A little further up the page that you quoted from this is explained.

Objects located in movable memory that are passed into an asynchronous call are copied into a location in non-movable memory for the duration of the asynchronous call. When the asynchronous call completes, the arguments are copied back to the original objects. If the object is not copied, the garbage collector may move the object during the call, resulting in unpredictable behavior.

So the answer is yes, all objects that are passed out to asynchronous calls of any sort are copied to FixedSpace.

This would be a huge saving, since our applications reads 500Mb of database data at startup which is then constant. Therefore, our garbage collection now hits 6.5 seconds and eats 65% of cpu.

Any hints much appreciated.

[marten]

Hi John,

Is there any way to force objects into fixed space without causing problems with garbage collection?

Object>>acoFix in application "ESAsynchonousCallout" ?

Marten

[vincid]

Thanks for the tip!

That does indeed seem to move things to fixed space but
1) it is fiendishly slow (probable because of some increment)
2) you have to do every object ('deep - acoFix')
3) the GC does not show any improvements yet

But it is what I was looking for and I'll experiment with it!

Kind regards,

Vincent

Hi John,

Is there any way to force objects into fixed space without causing problems with garbage collection?

Object>>acoFix in application "ESAsynchonousCallout" ?

Marten

[vincid]

Follow up:

That does indeed seem to move things to fixed space but
1) it is fiendishly slow (probable because of some increment)
2) you have to do every object ('deep - acoFix')
3) the GC does not show any improvements yet

There must be a smarter way to do this.
Using #acoFix = #makeFixed on my objects runs literally for days . I sincerely hope I'm doing something wrong.
Even reserving 256Mb of fixed space initially makes no difference whatsoever.

Does anybody have any good ideas for a block-makeFixed, given that these objects come from a database?

[wembley]

Vincent -

I mailed this back as the response to Case 35617, but I thought I would post it here as well for the information of others.

Moving objects into FixedSpace is not the right approach since it doesn't keep them from participating in GGC (as you've noticed).

Ignoring the scavenging of NewSpace objects, GGC is a 2-phase mark-and-sweep operation: first all the live objects are marked (which requires scanning FixedSpace objects for references to non-FixedSpace objects; then the live objects are swept up by compacting them into new memory segments. So, what you're saving by moving objects into FixedSpace is the actual movement of the objects during compaction.

What I suggest is that you want to get your database objects into OldSpace as rapidly as possible (see Behavior>>#newTenured and #newTenured: for methods that create objects in OldSpace rather than NewSpace, although using these methods is probably overkill). Then force a GGC to compact OldSpace. This will give you effectively the same performance profile during application execution as moving the objects into FixedSpace (without the effort).

Now you need to experiment with setting the initial sizes of OldSpace and NewSpace. You want to make OldSpace sufficiently large that GGC will never occur (or occur very infrequently) -- remember that GGC will only occur just before a new OldSpace memory segment needs to be allocated, so if you never need to grow OldSpace, you will not do GGCs. Also make the MemorySegment size large so you get a good large amount of memory when and if you do need to dynamically increase the size of OldSpace. And finally, experiment with increasing the size of NewSpace to reduce the number of middle-aged objects that get tenured into OldSpace (this is a bit of a tradeoff since it will cause more objects to be copied during scavenging -- that's why I use the term 'experiment').

You can use the MemoryMonitor Tool to see the effects of your changes.

[vincid]

Hi John,

Now you need to experiment with setting the initial sizes of OldSpace and NewSpace.

Thanks - this works perfectly.
In our case, where we load about 400Mb of data and sundry exprenses at startup, the following settings in abt.ini work fine:

Code: Select all

[VM Options]
newSpaceSize=16777216
oldSpaceSize=536870912
;since the loaded constants + product data should fit here (400Mb) + 100Mb free space
allocationIncrement=16777216
lowMinimum=4194304

This indeed limits the GC to a minimum without noticably affecting performance elsewhere.

What I suggest is that you want to get your database objects into OldSpace as rapidly as possible (see Behavior>>#newTenured and #newTenured: for methods that create objects in OldSpace rather than NewSpace, although using these methods is probably overkill).

Agreed - the effect is not really noticable and #newTenured instead of #new is a pain, since you then need to handle initialization of standard objects like Dictionaries by hand. Our db objects are of a class that is also used live, so we can't even override the construction.

You can use the MemoryMonitor Tool to see the effects of your changes.

Indeed. Especially the behaviour when the oldspace gets full is instructive.

Thanks for solving our problems!

One additional question, for interests sake: Is it really not possible to completely protect objects from the GC, like packeged code?