- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] LRUCache for high latency stuff

by Thierry Goubier

Hi Sven, 2014-11-03 22:52 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Thierry, > > > On 31 Oct 2014, at 14:10, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Hi all, > > > > I tried to use LRUCache for some application of mine with a two stages, > over-the-internet data requests, and I couldn't find a way of using it. > > > > My use case was: > > - retrieve some data with high latency (over 10 seconds) > > - in a interactive application, where I need to be able to continue > while the data is being loaded. > > > > So I designed it in two stages: > > - Have a cache > > - if the data isn't in the cache > > -- trigger a load with a fork > > -- put some temporary data in the cache (something which says loading) > > -- continue > > - When the data load is terminated > > -- replace the cached temporary data with the final version. > > > > The thing is that I couldn't do the last one with the LRUCache (there is > not at:put:, only a at:ifAbsentPut: []). Did I miss something? > > > > Thierry > > Relevant question and a rather special use case I would say. > > The API of AbstractCache and its subclasses is minimal by design. It > certainly does not contain everything that Dictionary has. > > A cache delivers values based on keys. The ifAbsent: block is similar to > the factory: block, it implements getting the value. Either you hit the > cache or you miss it and it gets loaded. Entries drop off either because > there are too many in some metric (LRUCache) or because they expire > (TTLCache). > > Now, #at:put: is like a replace, is it a hit or a miss ? Or neither ? > It would be a replace, and neither a hit nor a miss. > > You could implement it with a #removeKey: and and #at:ifAbsent: - modulo > some concurrent access problems. > I do those operations under a mutex, otherwise the system becomes incoherent :) > > Maybe we should add it (I guess it could be useful to fill a cold cache as > well) - but I am not totally convinced. > > Now, your use case is a bit odd and dangerous. You spawn a thread/process > for each miss, there could be a large number of them - do you want that ? > Will the value always/still be needed when it arrives ? > A non needed value (to late value) will be discarded almost immediately, so this is not an issue. The number of threads may be high, yes, but it stays apparently within reasonable limits (how many Zn requests one can do simultaneously from Pharo? Is there any throttling?). > > One way to implement your use case would be to encapsulate your special > behaviour (the delayed loading) in the value itself (since you have the two > cases/states exposed), no ? > Yes. This is more or less what I implemented, but without merging them in a single object. This makes using the LRUCache as is, but is no better than the previous approach about the number of threads in flight (those could be solved by a sharedQueue and a few loading processes feeding themselves out of the shared queue). Now I know how to use the LRUCache, but I think my use case is in a way too simple for its features (no real TTL, LRU only works if the cache size is over a certain threshold and that threshold isn't static). Thanks, Thierry > > Sven > > >

Nov. 3, 2014

Re: [Pharo-dev] LRUCache for high latency stuff

by Sven Van Caekenberghe

Hi Thierry, > On 31 Oct 2014, at 14:10, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi all, > > I tried to use LRUCache for some application of mine with a two stages, over-the-internet data requests, and I couldn't find a way of using it. > > My use case was: > - retrieve some data with high latency (over 10 seconds) > - in a interactive application, where I need to be able to continue while the data is being loaded. > > So I designed it in two stages: > - Have a cache > - if the data isn't in the cache > -- trigger a load with a fork > -- put some temporary data in the cache (something which says loading) > -- continue > - When the data load is terminated > -- replace the cached temporary data with the final version. > > The thing is that I couldn't do the last one with the LRUCache (there is not at:put:, only a at:ifAbsentPut: []). Did I miss something? > > Thierry Relevant question and a rather special use case I would say. The API of AbstractCache and its subclasses is minimal by design. It certainly does not contain everything that Dictionary has. A cache delivers values based on keys. The ifAbsent: block is similar to the factory: block, it implements getting the value. Either you hit the cache or you miss it and it gets loaded. Entries drop off either because there are too many in some metric (LRUCache) or because they expire (TTLCache). Now, #at:put: is like a replace, is it a hit or a miss ? Or neither ? You could implement it with a #removeKey: and and #at:ifAbsent: - modulo some concurrent access problems. Maybe we should add it (I guess it could be useful to fill a cold cache as well) - but I am not totally convinced. Now, your use case is a bit odd and dangerous. You spawn a thread/process for each miss, there could be a large number of them - do you want that ? Will the value always/still be needed when it arrives ? One way to implement your use case would be to encapsulate your special behaviour (the delayed loading) in the value itself (since you have the two cases/states exposed), no ? Sven

Nov. 3, 2014

Re: [Pharo-dev] ImageCleaner interaction with Delay

by Ben Coman

Marcus Denker wrote: >> On 02 Nov 2014, at 19:19, Ben Coman <btc(a)openInWorld.com> wrote: >> >> >> ImageCleaner>>cleanUpForRelease calls >>cleanUpMethods which calls >> Delay class>>startTimerEventLoop. I thought this would have started with a clean/empty suspended delays heap, but it carries forward >> the old SuspendedDelays. >> >> So if there happened to be a suspended delay expiring in a month's time, >> that would not be affected by ImageCleaner and would end up in the release. >> >> I believe the correct behaviour would be for ImageCleaner to produce a clean/empty suspended delays, and so that no waiting processing get stuck, signal any remaining suspended delays when the timer event loop is stopped by Delay class>>stopTimerEventLoop. >> >> Any objections? >> > > No, sounds good. > > #cleanUpMethods is supposed to re-start all methods that hold on to existing blocks, so that the compiled methods they hold on to get GCed. > (e.g. very important when compiler changes are done to not have old methods around). > > At some point I added it to the #cleanUpForRelease as it does not hurtâ¦ > > (and #cleanUpForRelease we all after every update as the final goal is to have the CI build be the release artefact unchannged) > > Marcus > > > > Thanks. I've added that on top of the slice Nicolai reviewed for my Delay refactoring @ https://pharo.fogbugz.com/default.asp?14261. cheers -ben

Nov. 3, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40351 Home: https://github.com/pharo-project/pharo-core

Nov. 3, 2014

[pharo-project/pharo-core] 27bfd3: 40351

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 27bfd36879b17e6012f9eeffd702073842607d7b https://github.com/pharo-project/pharo-core/commit/27bfd36879b17e6012f9eeff… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-03 (Mon, 03 Nov 2014) Changed paths: M Kernel.package/CompiledMethod.class/instance/comparing/sameLiteralsAs_.st M Manifest-Tests.package/SmalllintManifestCheckerTest.class/instance/running/tearDown.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script351.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40351.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/AbstractApiSetter.class/instance/initialize/setValueTo_.st M Spec-Tools.package/AbstractApiSetter.class/instance/protocol/updateWith_.st M Spec-Tools.package/ChangeSorterApplication.class/instance/menu/changeSetMenu_shifted_.st M Spec-Tools.package/ChangeSorterApplication.class/instance/menu/classMenu_shifted_.st M Spec-Tools.package/ChangeSorterApplication.class/instance/menu/messageMenu_shifted_.st M Spec-Tools.package/ConfigurationGenerator.class/instance/metacello/addMetacelloBaseline.st M Spec-Tools.package/ConfigurationGenerator.class/instance/metacello/createVersionForBlessing_.st M Spec-Tools.package/ConfigurationGenerator.class/instance/metacello/dependentPackages.st M Spec-Tools.package/DiffChangeRecordConverter.class/definition.st M Spec-Tools.package/DiffChangeRecordConverter.class/instance/private/priorVersionOfAMethod_.st M Spec-Tools.package/DiffMorphChangeRecordConverter.class/definition.st M Spec-Tools.package/DualChangeSorterApplication.class/instance/event/refeshedChangeSet_.st M Spec-Tools.package/DualChangeSorterApplication.class/instance/menu - change set/checkThatSidesDiffer_.st M Spec-Tools.package/DualChangeSorterApplication.class/instance/menu - class/moveClassFrom_to_.st M Spec-Tools.package/DualChangeSorterApplication.class/instance/menu/changesMenu_shifted_from_to_.st M Spec-Tools.package/MessageBrowser.class/definition.st M Spec-Tools.package/MessageBrowser.class/instance/initialization/initialize.st R Spec-Tools.package/MessageBrowser.class/instance/protocol/title_.st M Spec-Tools.package/MessageBrowser.class/instance/testing/sortClassesInCachedHierarchy_b_.st M Spec-Tools.package/MessageBrowser.class/instance/text selection/searchedString_in_.st M Spec-Tools.package/NewVersionBrowser.class/definition.st M Spec-Tools.package/NewVersionBrowser.class/instance/menu/compareToOtherVersion.st M Spec-Tools.package/WorkingCopyToolBar.class/definition.st R Spec-Tools.package/WorkingCopyToolBar.class/instance/initialization/initialize.st M Spec-Tools.package/WorkingCopyToolBar.class/instance/initialize/createPackage.st M Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/instance/running/tearDown.st Log Message: ----------- 40351 14246 CompiledMethod>>hash can produce clashes https://pharo.fogbugz.com/f/cases/14246 14379 Code critique pass Spec-Tools https://pharo.fogbugz.com/f/cases/14379 14375 Random #obsoleteClasses test failures https://pharo.fogbugz.com/f/cases/14375 http://files.pharo.org/image/40/40351.zip

Nov. 3, 2014

Re: [Pharo-dev] ImageCleaner interaction with Delay

by Marcus Denker

> On 02 Nov 2014, at 19:19, Ben Coman <btc(a)openInWorld.com> wrote: > > > ImageCleaner>>cleanUpForRelease calls >>cleanUpMethods which calls > Delay class>>startTimerEventLoop. I thought this would have started with a clean/empty suspended delays heap, but it carries forward > the old SuspendedDelays. > > So if there happened to be a suspended delay expiring in a month's time, > that would not be affected by ImageCleaner and would end up in the release. > > I believe the correct behaviour would be for ImageCleaner to produce a clean/empty suspended delays, and so that no waiting processing get stuck, signal any remaining suspended delays when the timer event loop is stopped by Delay class>>stopTimerEventLoop. > > Any objections? > No, sounds good. #cleanUpMethods is supposed to re-start all methods that hold on to existing blocks, so that the compiled methods they hold on to get GCed. (e.g. very important when compiler changes are done to not have old methods around). At some point I added it to the #cleanUpForRelease as it does not hurtâ¦ (and #cleanUpForRelease we all after every update as the final goal is to have the CI build be the release artefact unchannged) Marcus

Nov. 3, 2014

Re: [Pharo-dev] Failing #obsoleteClasses test

by Marcus Denker

> On 02 Nov 2014, at 19:39, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 02.11.2014, at 18:28, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Max, >> >> could the cache be reimplemented using WeakArray? Stuff like this is a drag. eg in Squeak the Windows menu holds onto all the windows that were open when last the menu was opened. So to get a window reclaimed after being closed if you opened the Windows menu you have to open it again. I must fix that. > > No idea. I really didnât look at what it does, I just tracked pointers ;) > > But yes, maybe that would be a good idea. Adding âASTCache reset.â all over the place is not really a good strategy. > > Iâll send a copy of this message to Marcus and ClÃ©ment; I suspect they might know more about the AST stuff. > Yesâ¦ I am not happy with the AST cache as it is now. for one, yes, it might hold on to things. And it can get large. So we definitely need to have a look. (I am actually amazed how well it works till nowâ¦ ;-) ). Marcus

Nov. 3, 2014

Re: [Pharo-dev] VersionnerRepositoriesManager - Why clear okAction?

by Sean P. DeNigris

demarey wrote > Maybe what you need is RemotesManager. I extracted this component from > Komitter. Thanks for the reply! Yes, I ended up using RemotesManager. ----- Cheers, Sean -- View this message in context: http://forum.world.st/VersionnerRepositoriesManager-Why-clear-okAction-tp47… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 3, 2014

Re: [Pharo-dev] [Vm-dev] Re: Super fast delay

by Ben Coman

Eliot Miranda wrote: > > Hi Ben, > > On Nov 2, 2014, at 6:06 AM, Ben Coman <btc(a)openInWorld.com> wrote: > >> Eliot Miranda wrote: >>> On Wed, Oct 29, 2014 at 12:14 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> Holger Hans Peter Freyther wrote: >>> On Wed, Oct 29, 2014 at 06:54:57PM +0100, Holger Hans Peter >>> Freyther wrote: >>> On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote: >>> Good Evening, >>> Hi again, >>> I don't know how you debug startUp issues. I just added an >>> OrderedCollection >>> into the systemdictionary and use it as a log.. >>> time ./bin/pharo --nodisplay ./TimerTest3.image eval "(Delay >>> forSeconds: 3) wait. (Smalltalk at: #Foo) do: [:each | >>> FileStream stderr nextPutAll: each printString; cr].1" >>> ... old events from saving the image... >>> {#handleTimerEvent->7147} >>> {#handleTimerEvent->7167} >>> {#resumptionTime->7187} >>> {#handleTimerEvent->7167} >>> {#handleTimerEvent->7187} >>> {#start->true} >>> {#start->393102159} >>> {#start->393102159} >>> {#resumptionTime->3279} >>> {#handleTimerEvent->279} >>> {#adjustResum->-393098880} >>> {#restoreWithActiveDelay->266} >>> {#adjustResum->-393098601} >>> 1 >>> real 0m0.294s >>> user 0m0.244s >>> sys 0m0.048s >>> So what happens is Delay class>>#startU is called. and >>> ActiveDelayStartTime is being set to 393102159. Then the >>> delay is being created and resumptionTime is set to 3279. >>> At the first time handleTimerEvent runs the milliSecondClock >>> jumped backwards from 393102159 to 3279 which leads to >>> an adjustment of the time. >>> a.) Why does the time jump backwards like this during the >>> resumption of the image? "3279" is not the old time nor >>> the new starting time. >>> b.) So even if that is a "wrap" around. Why does it go >>> wrong? Are there unit tests for the clock wraps around? >>> There are no unit tests, I guess since its all done using class >>> variables its too hard test without disturbing the system. >>> Now I have spent the last week refactoring this out to the >>> instance-side of a new class "DelayScheduler" which should help with >>> getting unit tests. Its ready for review [1], maybe you could take >>> a look. >>> [1] https://pharo.fogbugz.com/__default.asp?14261 >>> <https://pharo.fogbugz.com/default.asp?14261> >>> Maybe it is the same reason delays just don't work after >>> image resumption? >>> The "first" issue appears that when start is being executed >>> that the clock is still wrong. At the same the clock is >>> being considered wrapped the resumption time was actually >>> already "correct' (3279 instead of 393102159+3279). >>> Does this ring a bell? >>> holger >>> btw, its too late in the night for me to try something, but I have >>> been wondering, should the check for clock roll-over occur >>> immediately after >>> TimingSemaphore wait >>> wakes up. That is, before the Schedule and Finish requests are >>> handled ??? >>> The check for rollover should be thrown away and the system implemented over the VM's support for 64-bit microseconds since 1901. It's in the VM, it isn't susceptible to rollover for ~ 50,000 years, and doesn't require the millisecond clock to be synced to the second clock, because all times can be derived from the one 64-bit microsecond clock. >>> -- >>> best, >>> Eliot >> The performance of the Delay timer event loop is noted in the code to be critical, however... >> >> "Time millisecondClockValue" returns a SmallInteger, which is an immediate object while "Time microsecondClockValue" returns a LargePositiveInteger, which is not. >> >> So theoretically will calculations and comparisons based on the second be slower ? Actually my performance testing so far hasn't found it to be slower, but I am interested in the general case. > > That comment was written when the context interpreter VM was the standard. Cog is much faster. That should more than make up for the small amount of large integer arithmetic the use of 64-bit microseconds involves. And once we switch to 64-bit Spur the 64-bit microsecond clock will once again be a SmalInteger. And if your measurements show you there isn't an issue then there isn't an issue. > Cool. Thanks for the info.

Nov. 3, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40350 Home: https://github.com/pharo-project/pharo-core

Nov. 3, 2014