[Help-smalltalk] _gst_invalidate_method_cache and _gst_reset_inline_caches

[Holger Hans Peter Freyther]

Good Evening,

I looked into the excessive calls to _gst_reset_inline_caches. They
are mostly due calls to _gst_invalidate_method_cache and are done in
case of:


1.) Creating a new call-in process (in interp.c). This looks wrong. How
  should a new process change the look-up of a method?

2.) Installing a new method.

3.) VMpr_Behavior_flushCache. E.g. in gst-browser when selecting a category
  the following is executed:

(ip 52)[] in MethodDictionary>>#at:put:
(ip 30)[] in Semaphore>>#critical:
(ip 6)<unwind> BlockClosure>>#ensure:
(ip 8)Semaphore>>#critical:
(ip 8)MethodDictionary>>#at:put:
(ip 10)MethodDictionary(LookupTable)>>#add:
(ip 12)[] in Dictionary>>#select:
(ip 8)[] in LookupTable>>#associationsDo:
(ip 32)MethodDictionary(LookupTable)>>#keysAndValuesDo:
(ip 8)MethodDictionary(LookupTable)>>#associationsDo:
(ip 20)MethodDictionary(Dictionary)>>#select:
(ip 28)GtkMethodWidget>>#category:
(ip 10)GtkMethodWidget>>#class:withCategory:
(ip 12)GtkClassBrowserWidget>>#updateInstanceSideMethodCategory:
(ip 14)CategoryState>>#updateBrowser:
(ip 8)GtkClassBrowserWidget>>#state:
(ip 6)[] in GtkClassBrowserWidget>>#updateState:
(ip 8)[] in GtkClassBrowserWidget>>#checkCodeWidgetAndUpdate:
(ip 24)GtkClassBrowserWidget>>#saveCodeOr:
(ip 8)GtkClassBrowserWidget>>#checkCodeWidgetAndUpdate:
(ip 14)GtkClassBrowserWidget>>#updateState:
(ip 12)GtkClassBrowserWidget>>#onInstanceSideCategoryChanged


Starting gst-browser with some instrumentation gives output like this:

WALKED 35333 ICs.. 35331 cold diff 2
WALKED 35333 ICs.. 35268 cold diff 65

...

showing that the caches are mostly flushed twice. When doing a

  3+3 CTRL-P

a.) WALKED 84729 ICs.. 84129 cold diff 600
b.) WALKED 84729 ICs.. 84727 cold diff 2
c.) WALKED 84729 ICs.. 84656 cold diff 73

a.) 
(ip 52)[] in MethodDictionary>>#at:put:
(ip 30)[] in Semaphore>>#critical:

b.)
#1  0xb7f74625 in _gst_invalidate_method_cache () at interp.c:2363
#2  0xb7f1ddb9 in install_method (address@hidden, classOOP=0x406306f0)
    at comp.c:2556

c.) 
(ip 38)[] in MethodDictionary>>#removeKey:ifAbsent:
(ip 30)[] in Semaphore>>#critical:
(ip 6)<unwind> BlockClosure>>#ensure:
(ip 8)Semaphore>>#critical:
(ip 6)MethodDictionary>>#removeKey:ifAbsent:
(ip 34)Behavior>>#removeSelector:ifAbsent:
(ip 38)GtkWorkspaceWidget(GtkTextWidget)>>#doWithoutForkIt:



Sorry. A lot of facts now some judgement and proposals.


Removing of calls:
1.) I think we can safely remove the flush from the call-in process
creation. This code has been there since the initial import.

2.) I think we can remove the invalidate from install_method in case
the kernel is initialized. In that case we will use >>#at:put: to
add the method that will already end in a flushCache.



Optimizations:

 MethodDictionary>>#select: will create a new MethodDictionary that
 will flush the cache when it is populated. It is wasteful and we could
 avoid this. It will only benefit VisualGST.


 Most inline caches are in-active (okay creating a VM that has both the
 jit and interpreter in one is another topic). The ideas we have talked
 about so far are:

 * OpenMP to make the invalidate spread across different cores
 * Add a global version to the IC. So the fast path would have an
   additional load, compare, branch.
 * Create a list or a flat array (and if more than 1024 entries) and
   add active entries there. So this would create additional calls
   on the hot path as well.


comments?

        holger