flushExternalPrimitives usage?
John M McIntosh
johnmci at smalltalkconsulting.com
Mon Aug 29 18:28:18 UTC 2005
I was benchmarking the VM late last night and checking startup time
and again noticed we invoke flushExternalPrimitives to scan over all
object memory
Interpreter>>flushExternalPrimitives
"Flush the references to external functions from plugin
primitives. This will force a reload of those primitives when
accessed next. "
On August 6, 2003 I had written a note "[ENH][VM] faster image
startup" about this and had a change set to reset only the method
contexts that we had noticed needed being reset in an earlier scan of
memory when we were either adjusting t the oops offset or to address
intel/powerpc issues.
However the comments in initialCleanup imply we only should do this
for earlier VM, not 3.8 or perhaps 3.6/3.7
I recall some discussion about changes to image saving so that new
images wouldn't have this problem and then not require the scan.
So did that fix get lost somewhere, or was an issue found and we
should again look at how many times we scan oops memory at startup time?
initialCleanup
"Images written by VMs earlier than 3.6/3.7 will wrongly have
the root bit set on the active context. Besides clearing the root
bit, we treat this as a marker that these images also lack a cleanup
of external primitives (which has been introduced at the same time
when the root bit problem was fixed). In this case, we merely flush
them from here."
((self longAt: activeContext) bitAnd: RootBit) = 0 ifTrue:
[^nil]. "root bit is clean"
"Clean root bit of activeContext"
self longAt: activeContext put: ((self longAt: activeContext)
bitAnd: AllButRootBit).
"Clean external primitives"
self flushExternalPrimitives.
--
========================================================================
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===
More information about the Vm-dev
mailing list