--- a/ExternalAddress.st Thu Mar 31 08:51:45 2016 +0100
+++ b/ExternalAddress.st Fri Apr 01 11:11:11 2016 +0100
@@ -40,23 +40,24 @@
documentation
"
- Instances of this class represent external (non-Smalltalk) addresses.
- They are only useful to represent handles as returned by C functions
- as smalltalk objects.
- For example, Window- or WidgetIDs (which are actually 32 bit pointers) could be represented this way
- (better create a handle-subclass for it, to care for proper finalization).
+ Instances of this class represent external (non-Smalltalk) memory addresses.
+ They are only useful to represent handles as returned by C functions,
+ or to pass them to C functions.
+ For example, Window- or WidgetIDs (which are actually 32 bit pointers) can be represented this way,
+ but better create a handle-subclass for it, to care for proper finalization.
(you should not use SmallIntegers for this, since they can only represent 31
bits; LargeIntegers could be used in theory, but it is not a very good style
to do so, since it makes things a bit cryptic - having ExternalAddresses
around makes things pretty clear in inspectors etc.).
- There is not much you can do with ExternalAddresses on the smalltalk level;
+ There is not much you can do with ExternalAddresses on the Smalltalk level;
creation/use should be done in primitive C-code via
__MKEXTERNALADDRESS(voidPtr) and __ExternalAddressVal(obj).
- ExternallAddresses are much like ExternalBytes - however, the latter
- allow you to access bytes via indexed at:/at:put: messages.
- ExternalAddresses do not allow such accesses (they are meant to remain anonymous, opaque handles).
+ ExternalAddresses are much like ExternalBytes - however, ExternalAddresses do not know
+ the size of the memory block and therefore do not allow you to access bytes via indexed at:/at:put: messages
+ (which ExternalBytes do).
+ ExternalAddresses are meant to remain anonymous, opaque handles.
Also, memory blocks which are freeable should be represented as ExternalBytes.
[author:]
--- a/ExternalBytes.st Thu Mar 31 08:51:45 2016 +0100
+++ b/ExternalBytes.st Fri Apr 01 11:11:11 2016 +0100
@@ -1,3 +1,5 @@
+"{ Encoding: utf8 }"
+
"
COPYRIGHT (c) 1993 by Claus Gittinger
All Rights Reserved
@@ -389,30 +391,34 @@
!ExternalBytes class methodsFor:'instance creation'!
-address:aNumber
- "return a new ExternalBytes object to access bytes starting at aNumber.
- The memory at aNumber has been allocated elsewhere. The size is not known,
- therefore byte accesses will NOT be checked for valid index.
+address:anAddressInteger
+ "return a new ExternalBytes object to access bytes starting at anAddressInteger.
+ The memory at anAddressInteger has been allocated elsewhere.
+ The size is not known, therefore byte accesses will NOT be checked for valid index.
Use this, if you get a pointer from some external source (such as a
C-callBack function) and you have to extract bytes from that.
DANGER ALERT: this method allows very bad things to be done to the
- system - use with GREAT care (better: do not use it)"
+ system - use with GREAT care (better: do not use it)"
- ^ self basicNew setAddress:aNumber size:nil
+ ^ self basicNew setAddress:anAddressInteger size:nil
+
+ "Modified (comment): / 31-03-2016 / 11:05:07 / cg"
!
-address:aNumber size:size
- "return a new ExternalBytes object to access bytes starting at aNumber.
- The memory at aNumber has been allocated elsewhere. The size is known,
- which allows byte accesses to be checked for valid index.
+address:anAddressInteger size:size
+ "return a new ExternalBytes object to access bytes starting at anAddressInteger.
+ The memory at anAddressInteger has been allocated elsewhere.
+ The size is known, which allows byte accesses to be checked for valid index.
Use this, if you get a pointer to a structure from some external source
(such as a C-callBack function) and you have to extract things from that.
DANGER ALERT: this method allows very bad things to be done to the
- system - use with GREAT care (better: do not use it)"
+ system - use with GREAT care (better: do not use it)"
- ^ self basicNew setAddress:aNumber size:size
+ ^ self basicNew setAddress:anAddressInteger size:size
+
+ "Modified (comment): / 31-03-2016 / 11:04:27 / cg"
!
new:numberOfBytes
@@ -462,7 +468,7 @@
!
newNullTerminatedFromWideString:aString
- "allocate a null terminated wide string containing the chars of aString"
+ "allocate a null terminated wide string containing the U16-chars of aString"
|nChars extBytes|
@@ -475,6 +481,8 @@
].
extBytes unsignedInt16At:((nChars+1)*2) put:0.
^ extBytes
+
+ "Modified (comment): / 31-03-2016 / 11:05:37 / cg"
!
unprotectedNew:numberOfBytes
--- a/ExternalLibraryFunction.st Thu Mar 31 08:51:45 2016 +0100
+++ b/ExternalLibraryFunction.st Fri Apr 01 11:11:11 2016 +0100
@@ -142,7 +142,7 @@
Synchronous vs. Asynchronous calls:
by default, foreign function calls are synchronous, effectively blocking the whole ST/X system
- (that is by purpose,´because most C-code is not prepared for being interrupted, and also, normal
+ (that is by purpose,because most C-code is not prepared for being interrupted, and also, normal
code is not prepared for a garbage collector to move objects around, while another C thread might
access the data...).
Therefore, the following will block all ST/X activity for 10 seconds
@@ -1006,7 +1006,7 @@
# define __HI32(ll) (((ll)>>32) & 0xFFFFFFFFL)
# endif
# endif
-
+#define VERBOSE
ffi_cif __cif;
ffi_type *__argTypesIncludingThis[MAX_ARGS+1];
ffi_type **__argTypes = __argTypesIncludingThis;
@@ -1189,7 +1189,7 @@
codeAddress = inst->vTable[__intVal(vtOffset)];
# ifdef VERBOSE
if (@global(Verbose) == true) {
- printf("virtual codeAddress: %"_lx_"\n", (INT)codeAddress);
+ printf("virtual %d codeAddress: %"_lx_"\n", __intVal(vtOffset), (INT)codeAddress);
}
# endif
}
@@ -1944,7 +1944,7 @@
^ returnValue
"Created: / 01-08-2006 / 13:56:23 / cg"
- "Modified: / 30-03-2016 / 13:44:11 / cg"
+ "Modified: / 31-03-2016 / 00:03:03 / cg"
"Modified: / 07-07-2015 / 22:21:56 / Jan Vrany <jan.vrany@fit.cvut.cz>"
!
--- a/ExternalStream.st Thu Mar 31 08:51:45 2016 +0100
+++ b/ExternalStream.st Fri Apr 01 11:11:11 2016 +0100
@@ -2958,13 +2958,16 @@
|bufferSize|
- OperatingSystem isMSDOSlike ifTrue:[
- "/ mhmh - NT hangs, when copying bigger blocks to a network drive - why ?
- bufferSize := 1 * 1024.
- ] ifFalse:[
- bufferSize := 8 * 1024.
+ (self isFileStream and:[outStream isFileStream]) ifTrue:[
+ bufferSize := 8192 * 8. "/ 64k buffer size
+ ] ifFalse:[
+ OperatingSystem isMSDOSlike ifTrue:[
+ "/ mhmh - NT hangs, when copying bigger blocks to a network drive - why ?
+ bufferSize := 1 * 1024.
+ ] ifFalse:[
+ bufferSize := 8 * 1024.
+ ].
].
-
^ self copyToEndInto:outStream bufferSize:bufferSize
"
--- a/ObjectMemory.st Thu Mar 31 08:51:45 2016 +0100
+++ b/ObjectMemory.st Fri Apr 01 11:11:11 2016 +0100
@@ -1,3 +1,5 @@
+"{ Encoding: utf8 }"
+
"
COPYRIGHT (c) 1992 by Claus Gittinger
All Rights Reserved
@@ -268,13 +270,18 @@
Interestingly, the scavenger performs better, if many garbage objects
are to be reclaimed, since less object-copying has to be done. Therefore,
the best-case scavenge time is almost zero, if there is only garbage in
- the newSpace. In contrast, the worst-case is when all newSpace objects are still
- living. Thus, from a newSpace collectors viewPoint, it makes sense to get
+ the newSpace.
+ In contrast, the worst-case is when all newSpace objects are still living.
+ Thus, garbage reclamation of young objects is basically free -
+ the more garbage is in newspace, the faster is the collector, asymptotically approaching
+ zero time, when all new objects are garbage!!
+
+ From the newSpace collector's viewPoint, it makes sense to get
objects out of the way as fast as possible. However the oldSpace is
collected much less frequently and the cost to reclaim an oldspace object
is much higher (actually, the cost to reclaim a newspace object is zero -
- its the survival of objects which we have to pay for).
- Therefore, from an oldSpace collectors point of view, its preferable to
+ it's the *survival* of objects which we have to pay for).
+ Therefore, from an oldSpace collector's point of view, it's preferable to
keep objects in the newSpace as long as possible.
To honor this conflicting situation, the system uses an adaptive tenure-count,
@@ -286,8 +293,8 @@
The exact speed of the scavenger depends mostly on the speed of your memory
interface (and, since most of todays memories have access times in the order
- of 50-100ns, the raw CPU speed does not correlate linear with the GC speed).
- Measurements give roughly 40ms for a full 400k newSpace
+ of 10-40ns, the raw CPU speed does not correlate linear with the GC speed).
+ Measurements (1992!!) give roughly 40ms for a full 400k newSpace
(i.e. all objects survive) on a 486/50 - this only drops to some 20-30ms on a P5.
Big caches help - i.e. a 1Mb cache machine performs better than a 256k cache machine.
Also, a good memory interface (small number of wait cycles and burst modes)
@@ -302,15 +309,17 @@
oldSpace:
To reclaim oldspace, the system uses three algorithms: mark&sweep, a copying
- (and compressing) baker-type collector and an incremental mark&sweep, augmented
- by an inplace compress algorithm.
-
- The mark&sweep runs whenever the oldspace becomes full, putting dead objects
- onto a free list. If a memory request cannot be served from this freelist,
- and the total size of objects on the freelist exceeds a threshold, the system
- will compress the oldspace to make the free-space into one big area.
+ (and compressing) baker-type collector and an incremental mark&sweep&compress.
+
+ The blocking mark&sweep runs whenever the oldspace becomes full and the oldSpace
+ limit has been reached (i.e. it prefers to map more pages to the oldSpace up to an
+ adjustable limit). It puts dead objects onto a free list.
+ If a memory request cannot be served from this freelist,
+ and the total size of objects on the freelist exceeds a threshold (actually: the fragmentation does so),
+ the system will compress the oldspace to make the free-space into one big area.
This compress is either done by a 1-pass semispace copy algorithm, or
- a 2pass inplace compress - depending on the setting of the compress limit.
+ a 2pass inplace compress - depending on the setting of the compress limit
+ (if lots of virtual address space is available, a 1-pass algorithm is chosen).
The 1pass algorithm copies all live objects into a newly allocated
area, and frees the previous memory afterwards (a baker style copying collector).
@@ -340,15 +349,15 @@
(see ProcessorSceduler>>waitForEventOrTimeout), or alternatively as a low or high
priority background process (see ObjectMemory>>startBackgroundCollector).
Like the normal mark&sweep, this incremental collector follows object references
- and marks reachable objects on its way. However, this is done 'a few objects-at-a-time',
- to not disrupt the system noticably.
+ and marks reachable objects on its way.
+ However, this is done 'a few objects-at-a-time', to not disrupt the system noticably.
Currently, there are some (theoretical) and in practice never occurring situations,
in which the incremental GC still creates noticable delays.
A current project is involved with this and a future version of ST/X (ST/X-RT)
will be available which shows deterministic worst case behavior in its GC pauses
(this will be provided as an additional add-on option - certainly not for free ;-).
- Currently, incremental GC blockings are in the order of 10-70ms.
+ Currently (1995), incremental GC blockings are in the order of 10-70ms.
There is one catch with low priority background IGC: if there is never any idle
time available (i.e. all processes run all the time), it would never get a chance
to do any collection work.
@@ -357,8 +366,9 @@
or it can be gicen a dynamic priority, where the max-prio is above UserSchedulingPriority.
A high priority background collector will always make progress and eventually finish
a GC cycle. However, it may have more of an influence on the other processes.
- So, its up to you, to decide ...
-
+ The default setup to date is to give it a dynamic priority, so it is ensured to make some
+ progress - although sometimes only slowly.
+ So, its up to you, to decide ...
Incremental garbage collection is controlled by the variables
'IncrementalGCLimit', 'FreeSpaceGCLimit' and 'FreeSpaceGCAmount':
@@ -418,55 +428,55 @@
Notice, that the defaults below are those of the VM and or ObjectMemory class.
These may already be changed by a smalltalk.rc or private.rc startup file.
- what default change by
- command line arg dynamically
+ what default change by
+ command line arg dynamically
-----------------------------------------------------------------------
- newSpace size 400k -Mnew nnn newSpaceSize:nnn
-
- oldSpace size 3000k -Mold nnn moreOldSpace:
- announceSpaceNeed:
- collectGarbage
-
- max tenure age 29 lockTenure:
- avoidTenure:
- (sets it to infinity)
-
- adaptive tenure - - tenureParameters
-
- 2pass oldSpace
- compressor enabled -Msingle -
-
- limit for 1pass
- old-compress 8000k - oldSpaceCompressLimit:
-
- chunk size
- to increase
- oldSpace 256k - oldSpaceIncrement:
-
- prefer moreOld
- to doing GC false - fastMoreOldSpaceAllocation:
-
- limit for
- above - - fastMoreOldSpaceLimit:
-
- keep size for - - freeSpaceGCAmount:
- IGC
-
- low water
- trigger for IGC - - freeSpaceGCLimit:
-
- allocated
- trigger for IGC 500k - incrementalGCLimit
-
- maximum time
- interval between
- IGC's - - BackgroundCollectMaximumInterval
-
- JIT codeCache
- size unlimited - dynamicCodeLimit:
-
- new JIT code
- trigger for IGC none - dynamicCodeGCTrigger:
+ newSpace size 400k -Mnew nnn newSpaceSize:nnn
+
+ oldSpace size 3000k -Mold nnn moreOldSpace:
+ announceSpaceNeed:
+ collectGarbage
+
+ max tenure age 29 lockTenure:
+ avoidTenure:
+ (sets it to infinity)
+
+ adaptive tenure - - tenureParameters
+
+ 2pass oldSpace
+ compressor enabled -Msingle -
+
+ limit for 1pass
+ old-compress 8000k - oldSpaceCompressLimit:
+
+ chunk size
+ to increase
+ oldSpace 256k - oldSpaceIncrement:
+
+ prefer moreOld
+ to doing GC false - fastMoreOldSpaceAllocation:
+
+ limit for
+ above - - fastMoreOldSpaceLimit:
+
+ keep size for - - freeSpaceGCAmount:
+ IGC
+
+ low water
+ trigger for IGC - - freeSpaceGCLimit:
+
+ allocated
+ trigger for IGC 500k - incrementalGCLimit
+
+ maximum time
+ interval between
+ IGC's - - BackgroundCollectMaximumInterval
+
+ JIT codeCache
+ size unlimited - dynamicCodeLimit:
+
+ new JIT code
+ trigger for IGC none - dynamicCodeGCTrigger:
By default, no incremental GC is started by the system; however,
@@ -474,28 +484,28 @@
You have to edit your startup files to change this.
A suggested configuration (used by the author and the default) is:
- ' keep 1meg in the pocket '
-
- ObjectMemory freeSpaceGCAmount:1000000.
-
- ' start incrementalGC when freespace drops below 250k '
- ' or 500k of oldSpace has been allocated '
-
- ObjectMemory freeSpaceGCLimit:250000. '
- ObjectMemory incrementalGCLimit:500000. '
-
- ' collect as a background process (the default is: at idle times)
- ' this means that running cubes or other demo processes are suspended
- ' for the collect; change the prio to below 4 if you want them to continue
-
- ObjectMemory startBackgroundCollectorAt:5. '
- ObjectMemory startBackgroundFinalizationAt:5. '
-
- ' quickly allocate more space (i.e. avoid blocking collects)
- ' up to 8meg - then start to collect if more memory is needed.
-
- ObjectMemory fastMoreOldSpaceLimit:8*1024*1024. '
- ObjectMemory fastMoreOldSpaceAllocation:true. '
+ ' keep 1meg in the pocket '
+
+ ObjectMemory freeSpaceGCAmount:1000000.
+
+ ' start incrementalGC when freespace drops below 250k '
+ ' or 500k of oldSpace has been allocated '
+
+ ObjectMemory freeSpaceGCLimit:250000. '
+ ObjectMemory incrementalGCLimit:500000. '
+
+ ' collect as a background process (the default is: at idle times)
+ ' this means that running cubes or other demo processes are suspended
+ ' for the collect; change the prio to below 4 if you want them to continue
+
+ ObjectMemory startBackgroundCollectorAt:5. '
+ ObjectMemory startBackgroundFinalizationAt:5. '
+
+ ' quickly allocate more space (i.e. avoid blocking collects)
+ ' up to 8meg - then start to collect if more memory is needed.
+
+ ObjectMemory fastMoreOldSpaceLimit:8*1024*1024. '
+ ObjectMemory fastMoreOldSpaceAllocation:true. '
hints & tricks:
@@ -508,37 +518,37 @@
control over allocation can speedup your programs; but please:
- if you think you have to play around with the memory policies,
- first check your program - you may find useless allocations
- or bad uses of collections. A typical error that is made is to
- create large collections using the #, (comma) concatenation method,
- which shows square behavior, since it allocates many, many temporary
- collections. Also, watch out for #copyWith:, #add: etc.
- All of these create a new collection. Remember, that most collections
- offer methods to preallocate some space; for example, 'Set new:' creates
- an empty set, but preallocates space to avoid resizing over and over.
-
- An especially bad performace dog is to use #add: on fix-size collection
- objects (such as Strings or Arrays), since in addition to allocating
- lots of garbage, a #become: operation is required for EACH element
- added. NEVER use Arrays for growing/shrinking data - use OrderedCollection
- instead. (if you really need an array, use asArray afterwards)
+ first check your program - you may find useless allocations
+ or bad uses of collections. A typical error that is made is to
+ create large collections using the #, (comma) concatenation method,
+ which shows square behavior, since it allocates many, many temporary
+ collections. Also, watch out for #copyWith:, #add: etc.
+ All of these create a new collection. Remember, that most collections
+ offer methods to preallocate some space; for example, 'Set new:' creates
+ an empty set, but preallocates space to avoid resizing over and over.
+
+ An especially bad performace dog is to use #add: on fix-size collection
+ objects (such as Strings or Arrays), since in addition to allocating
+ lots of garbage, a #become: operation is required for EACH element
+ added. NEVER use Arrays for growing/shrinking data - use OrderedCollection
+ instead. (if you really need an array, use asArray afterwards)
- if you are going to allocate huge data structures, think about
- optimizing space. For example, if you allocate a million instances of
- some object, each added instance variable makes up 4Mb of additional
- memory need.
- Also, for Byte-valued, Integer-valued and Float like objects, special
- collections are provided, which store their values directly inside (instead
- of a reference to the object). A FloatArray consisting of 1 million floats
- requires about 4mb of memory, while an Array of Floats requires 4mb for the
- references to the floats, PLUS 20Mb for the floats themself.
+ optimizing space. For example, if you allocate a million instances of
+ some object, each added instance variable makes up 4Mb of additional
+ memory need.
+ Also, for Byte-valued, Integer-valued and Float like objects, special
+ collections are provided, which store their values directly inside (instead
+ of a reference to the object). A FloatArray consisting of 1 million floats
+ requires about 4mb of memory, while an Array of Floats requires 4mb for the
+ references to the floats, PLUS 20Mb for the floats themself.
- check if you really need fast access to all of these objects; you may
- try to only keep some subset in memory, and use binary storage or
- (if this is too slow) optimized store/retrieve methods and keep the bigger
- part in a file.
- (How about a DiskArray class, which does this transparently ?
- See the FileText class for some ideas and something to start with ...)
+ try to only keep some subset in memory, and use binary storage or
+ (if this is too slow) optimized store/retrieve methods and keep the bigger
+ part in a file.
+ (How about a DiskArray class, which does this transparently ?
+ See the FileText class for some ideas and something to start with ...)
Hint / Example 1:
--- a/Smalltalk.st Thu Mar 31 08:51:45 2016 +0100
+++ b/Smalltalk.st Fri Apr 01 11:11:11 2016 +0100
@@ -617,7 +617,7 @@
this is NOT called when an image is restarted;
in this case the show starts in Smalltalk>>restart."
- |idx|
+ |idx shellArgs|
NumberOfClassesHint := 10000.
@@ -638,6 +638,33 @@
self initializeVerboseFlags.
DebuggingStandAlone := Debugging := false.
+
+ "/ if no argument was given, look for an environment variable named
+ "/ STX_DEFAULT_ARGS. If set, take that.
+ "/ if any argument was given, unless a --noShellArgs argument is given,
+ "/ slice in the value from "STX_MORE_ARGS" at the beginning.
+ "/
+ "/ These allow for args like "--quick --infoPrint" to be automatically prepended
+ idx := CommandLineArguments indexOfAny:#('--noShellArgs' '--noshellargs').
+ (idx ~~ 0) ifTrue:[
+ CommandLineArguments removeIndex:idx.
+ ] ifFalse:[
+ CommandLineArguments isEmpty ifTrue:[
+ shellArgs := OperatingSystem getEnvironment:'STX_DEFAULT_ARGS'.
+ shellArgs notEmptyOrNil ifTrue:[
+ shellArgs := shellArgs asCollectionOfWords.
+ CommandLineArguments addAll:shellArgs.
+ ].
+ ] ifFalse:[
+ "/ prepend shell environment args from "STX_ARGS"
+ shellArgs := OperatingSystem getEnvironment:'STX_MORE_ARGS'.
+ shellArgs notEmptyOrNil ifTrue:[
+ shellArgs := shellArgs asCollectionOfWords.
+ CommandLineArguments addAllFirst:shellArgs.
+ ].
+ ].
+ ].
+
idx := CommandLineArguments indexOf:'--debug'.
Debugging := (idx ~~ 0).
--- a/UninterpretedBytes.st Thu Mar 31 08:51:45 2016 +0100
+++ b/UninterpretedBytes.st Fri Apr 01 11:11:11 2016 +0100
@@ -1,5 +1,3 @@
-"{ Encoding: utf8 }"
-
"
COPYRIGHT (c) 1993 by Claus Gittinger
All Rights Reserved
@@ -746,7 +744,7 @@
longLongAt:index
"return the 8-bytes starting at index as a signed Integer.
The index is a smalltalk index (i.e. 1-based).
- The value is retrieved in the machineÄs natural byte order.
+ The value is retrieved in the machineÄs natural byte order.
This may be worth a primitive."
^ self signedInt64At:index MSB:IsBigEndian
@@ -2633,25 +2631,17 @@
pointer = ((char **)cp)[0];
RETURN (__MKUINT((INT)(pointer)));
} else {
-#if 0
- printf("cp UNALIGNED (%"_lx_")\n", (INT)cp);
-#endif
+ // printf("cp UNALIGNED (%"_lx_")\n", (INT)cp);
}
} else {
-#if 0
- printf("idx(%"_ld_")+(sizeof(pointer)-1) (%d) >= sz (%"_ld_")\n",
- idx, (int)(sizeof(pointer)-1), sz);
-#endif
+ // printf("idx(%"_ld_")+(sizeof(pointer)-1) (%d) >= sz (%"_ld_")\n",
+ // idx, (int)(sizeof(pointer)-1), sz);
}
} else {
-#if 0
- printf("cp is NULL\n");
-#endif
+ // printf("cp is NULL\n");
}
} else {
-#if 0
- printf("bad index\n");
-#endif
+ // printf("bad index\n");
}
bad:;
%}.
@@ -3414,7 +3404,7 @@
if ((idx >= 0) && ((idx+(2-1)) < sz)) {
int iVal;
-printf("1\n");
+
cp += idx;
if (msb == false) {
#if defined(__i386__) || (defined(__LSBFIRST__) && defined(UNALIGNED_FETCH_OK))