Could not load VMMaker in 10315

Hi

I did

ScriptLoader loadFFI
Then loaded VMMaker-dtl.122
Then proceeded when asked about klatt.

And I got Cannot compile -- stack including temps is too deep

what did I miss?

Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

From: Eliot Miranda <eliot.miranda <at> gmail.com>
Subject: Re: [Vm-dev] Fwd: [Pharo-project] Could not load VMMaker in  
10315
Newsgroups: gmane.comp.lang.smalltalk.squeak.general,  
gmane.comp.lang.smalltalk.squeak.vm.devel
Date: 2009-05-24 20:44:52 GMT (10 minutes ago)



On Sun, May 24, 2009 at 1:13 PM, John M McIntosh <johnmci <at>  
smalltalkconsulting.com> wrote:



Begin forwarded message:

From: Stéphane Ducasse <stephane.ducasse <at> inria.fr>
Date: May 24, 2009 1:35:01 AM PDT (CA)
To: Pharo Development <Pharo-project <at> lists.gforge.inria.fr>
Subject: [Pharo-project] Could not load VMMaker in 10315
Reply-To: Pharo-project <at> lists.gforge.inria.fr

Hi

I did

ScriptLoader loadFFI
Then loaded VMMaker-dtl.122
Then proceeded when asked about klatt.

And I got Cannot compile -- stack including temps is too deep

what did I miss?

Nothing.  There is a method in the GeniePlugin who's stack is too deep  
to compile with closures.  Here are some workarounds and solutions in  
increasing levels of difficulty:

1. since the GeniePlugin is inessential simply move it to another  
package and ignore the problem (this is what we have done at Qwaq).

2a. Since the method is never executed one can temporarily change the  
stack limit (e.g. CompiledMethod classPool at: #LargeFrame put: 57)  
and load the package, reverting the stack limit after loading  
(Compiledmethod classPool at: #LargeFrame put: 56)

2b. change CompiledMethod>>needsFrame: so that proceeding from the  
error still creates a compiled method (i.e. remove the ^ return from  
the method so that it reads
         needsFrameSize: newFrameSize
                 "Set the largeFrameBit to accomodate the newFrameSize"
                 | largeFrameBit header |
                 largeFrameBit := 16r20000.
                 (self numTemps + newFrameSize) > LargeFrame ifTrue:
                         [self error: 'Cannot compile -- stack  
including temps is too deep'].
                 header := self objectAt: 1.
                 (header bitAnd: largeFrameBit) ~= 0
                         ifTrue: [header := header - largeFrameBit].
                 self objectAt: 1 put: header
                                 + ((self numTemps + newFrameSize)  
 > SmallFrame
                                                 ifTrue:  
[largeFrameBit]
                                                 ifFalse: [0])

then file-in the method and proceed through the warning.
Both of these are tedious but since you're probably not going to be  
changing the method and since Monticello won't recompile it once it is  
loaded it'll sit there quite happily once compiled.

3. refactor the GeniePlugin method into an outer args parser and an  
inner engine method and solve the problem.  Since VMMaker will inline  
anyway this shouldn't make performance worse.  I haven't done this  
because I'm not the author and it is quite a complex method.

4. modify the Closure compiler so that it reuses temporaries in  
optimized blocks.  The method compiles with the BlueBook compiler  
because in
1 to: n do: [:i| .......].
...
1 to: n do: [:i| .......].
the two block variables "i" are the same "physical" variable stored in  
the same location in the home context (because BlueBook blocks do not  
have local arguments or temporaries).
But in the Closure compiler they are logically distinct variables and  
if the blocks were real and not optimized they would occupy different  
"physical" locations.  Since they are optimized blocks their  
temporaries do get allocated in the home context, but they occupy  
different locations, and hence the stack size is larger in the Closure  
compiler.  The Closure compiler could be modified to use a more  
sophisticated temporary variable scope analysis that would allow it to  
determine that the first block's "i" is out of scope when the second  
block is compiled and hence that the location can be reused.
This is non-trivial because it requires rewriting much of the  
temporary scope management (see TempVariableNode>>scope[:] & senders  
of scope:).  If I had hit the stack limit in more than this one method  
I probably would have tried to solve this but for now there are fatter  
fish to fry.


I plan that eventually the Cog VM will support a CompiledMethod format  
that will have a higher argument, temp and total frame size limit, but  
this isn't a priority right now.

Apologies
Eliot



Stef

_______________________________________________
Pharo-project mailing list
Pharo-project <at> lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
=
=
=
========================================================================
John M. McIntosh <johnmci <at> smalltalkconsulting.com>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================









On May 24, 2009, at 10:35 AM, Stéphane Ducasse wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project