ProfMonitor sampling bias on GemConnect
Because GemConnect uses a user action library, it is subject to server
bug 41283.
When the ProfMonitor sample timer fires while user action C code is executing,
the sample is not actually taken until control returns back to smalltalk.
This is usually when the user action code finishes and control has returned
back to the calling smalltalk method. But if the user action code makes
a smalltalk callback, the sample will be taken in that smalltalk method.
In both cases this can result in a sampling bias toward these methods,
leading to higher than expected tally counts and percentages for these
methods.
For GemConnect, this will be most noticible for methods:
GsRdbReadStream(class)>>newForConnection:
(called during GsOracleConnect>>openCursorOn:*)
DateTime>>_adjustForLocalOffset
(called during GsRdbReadStream operations returning date/time information)
System(class)>>_processDeferredGciUpdates
(called during GsRdbReadStream scanning operations)
Collection>>remove:*
(called during GsRdbReadStream>>free)
In addition, any methods that are used as accessor or setter methods in
a rdbColumnMapping may also exhibit some bias.
Workaround
No workaround. Be aware of this behavior when using ProfMonitor on code
that uses GemConnect.
Last updated: 10/2/23