On Wed, Apr 5, 2017 at 2:16 AM, Eliot Miranda <[email protected]> wrote:
> Hi Pavel, > > On Tue, Apr 4, 2017 at 1:15 AM, Pavel Krivanek <[email protected]> > wrote: > >> >> >> 2017-04-03 15:00 GMT+02:00 Esteban Lorenzano <[email protected]>: >> >>> Hello, >>> >>> This are the things I believe still needs to be solved to be able to >>> release Pharo 6.0: >>> >>> VM: >>> === >>> - win32, cairo fonts problem (I submitted a new VM to test, I think this >>> is fixed :P) >>> - make all tests pass (there are still some failing tests when compiling >>> a new VM)/. >>> - libgit2: Still not there, Jan and Ben were trying and sent some >>> suggestions but I still didn’t had the time to test it. >>> >>> Image: >>> ===== >>> >>> - iceberg still needs to go inside the image, I’m running to release >>> version 0.4 (maybe this week?) and then we can integrate. >>> - I'm still convinced there is a leak. I need to check this in detail. >>> And of course some help on this… Pavel?… would be cool :) >>> >> >> I have found one memory leak related to subscription type mixing: >> https://pharo.fogbugz.com/f/cases/19911 >> >> Then I had here a really huge image with 1.2 GB with all known memory >> leaks solved. It was leaking because of Undeclared, after cleaning of them >> (Undeclared removeUnreferencedKeys) it shrinked to 59 MB. >> >> In this particular case it was caused by code like this: >> >> initialize >> super initialize. >> noBindingBlock := [ objectSpace nilObject ] >> >> because noBindingBlock was undeclared, it created a reference from >> globals (Undeclared) to a particular context with all mess it referenced. >> >> Not sure if we should make some action like clean Undeclared before every >> snapshot. But the case like this is quite obscure and the information that >> people should beware it should be enough. >> > > Cleaning Undeclared arbitrarily is a very bad idea. Undeclared is where > we can find and eliminate Undeclared variables. Just eliminating them from > Undeclared does not solve the problem. The variables are still referenced > in coded. But when one removes them from Undeclared they become harder to > find. > > Instead the right solution is > a) to have tests in the standard test suite that check that Undeclared is > empty. If Undeclared is not empty the test should fail. > b) in any packaging or release process that produces a clean image there > should be a check for Undeclared being empty, and the build should fail if > it is not empty. > c) Smalltalk programmers should understand how undeclared variables work > in Smalltalk: > > Variables are declared either in some global pool such as Smalltalk, > TextConstants or a class pool (the dictionary holding class variables), or > as instance variables of a class, or as arguments and temporary variables > of a method. These are the only variables in the language. When the > compiler sees a variable name it searches for it, first amongst arguments > and temporaries, second amongst instance variables, third amongst class > variables, fourth amongst the class's imported pools, fifth in globals > (Smalltalk) and finally in Undeclared. If the variable is not found in any > of these places then a binding is created in Undeclared and that is used to > implement the variable. So undeclared variables are compiled as globals in > Undeclared. > > Whenever a variable is declared in a global pool (Smalltalk, a shared pool > or a class pool) the compiler checks for a binding in Undeclared and uses > that if it exists. Adding a class declares the class's binding in > Smalltalk. So uses of variables before they are declared get fixed up on > declaration without having to recompile the entire system. This is how the > system manages circularities amongst classes. A reference to a class that > has yet to be installed will be compiled as a reference to a binding in > Undeclared. When the class is installed it is set as the value of the > Undeclared binding, and the binding is moved from Undeclared to Smalltalk. > > When an instance variable is defined in a class that changes the shape of > the class's instances and so the class's methods are recompiled and that > will bind any undeclared references to the instance variable correctly. > > So an entry in Undeclared is > a) an indication that somewhere there is a missing declaration > b) a place where one can look for references to the undeclared binding > (references in the dictionary inspector, and I hope the Glamour inspector, > that opens when one inspects Undeclared) > c) a simple mechanism for allowing circular references amongst classes > > So under no circumstances remove bindings from Undeclared unless there are > no references from code to those bindings. There is a method that does > this: > Undeclared removeUnusedBindings > > HTH > Very informative. Thanks for that insight. Maybe should capture it for Deep Into Pharo (but I'm off to bed right now) cheers -ben > > >> Cheers, >> -- Pavel >> >> >>> List is a lot smaller now :) >>> If everything goes well, we can target to release next week. >>> >>> Next: >>> - Test the new process and tape some videos explaining how we will >>> contribute with a bootstrapped process using github :) >>> >>> cheers! >>> Esteban >>> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >
