You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
...
0.170000 0.010000 0.180000 ( 0.132127)
0.190000 0.000000 0.190000 ( 0.119628)
0.130000 0.000000 0.130000 ( 0.130361)
0.230000 0.010000 0.240000 ( 0.126183)
Error: Your application used more stack memory than the safety cap of 2048K.
Specify -J-Xss####k to increase it (#### = cap size in KB).
Specify -w for full java.lang.StackOverflowError stack trace
I can't reproduce this without singleton.rb. It seems to be an oddity tied to the fact that this benchmark repeatedly reopens and singletonizes the same class. It may not be a common pattern.
Ok, I found the issue. I knew it was there but did not realize it could cause this problem.
Constant caching for indy invalidates based on two things: global invalidation of that constant name, whenever a new value is set somewhere; and if the target module is different than the last time (for inheritance searches a la Foo::Bar). If we invalidate because we encountered a new time, we turn the constant site into a PIC and cache the new value along with previous ones. If we invalidate because of something global, we want to clear the site, since all cached values are now invalid.
The broken logic unfortunately just build a chained PIC endlessly for both invalidation cases. The one here is for normal constant lookup, which does both a lexical search and a hierarchy search (searchConst) and only invalidates globally. Every time the global invalidation fired, it caused the constant lookups in Singleton#included to add another link to the chain. The logic in singleton.rb triggered a global invalidation every time, so these cached links were all dead. Every lookup then had to traverse a longer and longer chain of invalidated SwitchPoint guards before caching again.
I have changes I'll push shortly that bring constant caching in line with method caching, which has invalidation and polymorphic limits.
Boom singletons have some problem with indy:
The text was updated successfully, but these errors were encountered: