On 27/06/12 18:05, Sean P. DeNigris wrote:
Germán Leiva wrote
OT: Late binding rocks!
Yes, and the latest binding would be to lookup at runtime. I have no idea
what the performance hit would be, or if we would use all that power, but
the idea is exciting :)
With proper caching at VM level, the performance overhead would be
negligible.
Typically, when a class is accessed, something like PUSH_GLOBAL insn
is generated. One may change semantics of this insns to do a proper
message send back, effectively doing something like (for instance)
self class resolveGlobalByName: globalName
This is very flexible and allows for very nice tricks.
This can be further performance-optimized. One may use a sort of an
inline cache keeping a pair - function pointer to a function that
returns desired value and a "cached data".
Initially, the function would be initialized to a function that calls
back smalltalk code like the one above. However, the smalltalk
code __may__ decide that the resolution is "stable" (i.e., next time the
code runs, same class should be returned) and fill the cache. The
standard smalltalk resolve method then would look like
resolveGlobalByName: globalName cache: cache
| v |
v := Smalltalk at: v
cache bindTo: v
where the cache is Smalltalk reflection object representing this
kind-of-inline cache.
When properly JITed, the cost of global access would the same as
before (except of the very first one) - ideally just one memory
fetch.
Cheers, Jan
--
View this message in context:
http://forum.world.st/Pharo-and-Namespaces-tp4636635p4636978.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
