[Pharo-dev] Esteban’s list of blocking issues for release Pharo 6.0 (updated to April 03)

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 4 14:16:19 EDT 2017


Hi Pavel,

On Tue, Apr 4, 2017 at 1:15 AM, Pavel Krivanek <pavel.krivanek at gmail.com>
wrote:

>
>
> 2017-04-03 15:00 GMT+02:00 Esteban Lorenzano <estebanlm at gmail.com>:
>
>> 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


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170404/52161572/attachment-0002.html>


More information about the Pharo-dev mailing list