yes, thanks to Eliot fixes, latest VMs are a lot more stable... but looks that the problem is still arising in certain weird situations :( On Mar 8, 2013, at 5:13 PM, Paul DeBruicker <pdebruic@gmail.com> wrote:
Does that happen when you use the VM from the top of the list here:
http://pharo.gforge.inria.fr/ci/vm/pharo/linux/
specifically: http://pharo.gforge.inria.fr/ci/vm/pharo/linux/pharo-linux-stable.zip
?
I haven't had the problem since switching to it when loading the config of Seaside 31 on Ubuntu 12.04
Sven Van Caekenberghe-2 wrote
Thanks.
But my 2nd and 3rd runs crashed, both at
Smalltalk stack dump: 0xbf9c4c18 M MethodDictionary(Object)>becomeForward: 0x79299080: a(n) MethodDictionary 0xbf9c4c44 M MethodDictionary>grow 0x79299080: a(n) MethodDictionary 0xbf9c4c5c M MethodDictionary(HashedCollection)>fullCheck 0x79299080: a(n) MethodDictionary 0xbf9c4c78 M MethodDictionary>at:put: 0x79299080: a(n) MethodDictionary
so it is still becomeForward: but while growing a MethodDictionary, which is a pretty basic operation I guess.
On 08 Mar 2013, at 15:46, Esteban Lorenzano <
estebanlm@
> wrote:
included :)
On Mar 8, 2013, at 2:52 PM, Sven Van Caekenberghe <
sven@
> wrote:
Hi Esteban,
On 08 Mar 2013, at 12:44, Esteban Lorenzano <
estebanlm@
> wrote:
Hi Sven,
One of the problems we currently have is that all method installation execute a becomeForward:, which is of course not terrible cleaver... I tried using the squeak implementation of it and everything looks working (and it has a small optimization that can help).
Can you trying the load by installing it?
CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have a completely different format. Therefore we need to generate a copy with new trailer, containing a srcPointer, and then #become it." | trailer copy start |
trailer := srcPointer = 0 ifTrue: [ "catch the common case of setting the source pointer to 0 when already 0" self sourcePointer = 0 ifTrue: [ ^ self ]. CompiledMethodTrailer empty ] ifFalse: [ CompiledMethodTrailer new sourcePointer: srcPointer ]. copy := self copyWithTrailerBytes: trailer.
"ar 3/31/2010: Be a bit more clever since #become: is slow. If the old and the new trailer have the same size, just replace it." (self trailer class == trailer class and:[ self size = copy size ]) ifTrue: [ start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ].
^self "will be copy if #become was needed"
this can help in the speed and also can help on the vm crash problem (even if it is a workaround)...
Esteban
I used the following version
CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have completely different format. Therefore we need to generate a copy with new trailer, containing scrPointer, and then become it."
| trailer copy | trailer := CompiledMethodTrailer new sourcePointer: srcPointer. copy := self copyWithTrailerBytes: trailer. "If possible do a replace in place as an optimization" (self trailer class == trailer class and: [ self size = copy size ]) ifTrue: [ | start | start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ]. ^ self
And it worked fine. My build completed successfully (1 try only). But it took about as long as before (10 minutes using a Cog based VM).
Thanks again for the suggestion, I think we should incorporate that change, no ?
The class test is ugly and most probably not necessary in the current image, I would say.
Sven
On Mar 8, 2013, at 11:53 AM, Sven Van Caekenberghe <
sven@
> wrote:
On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <
sven@
> wrote:
But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible.
To continue my rant (sorry ;-) about the problem with slow code loading.
These are some benchmarks on the same machine:
$ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 106532
$ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 221708
So it takes like 3 minutes to recompile every method in the system.
How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ?
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
-- View this message in context: http://forum.world.st/VM-Crashes-tp4675526p4675784.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.