On Fri, Aug 27, 2010 at 1:30 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Ok if I understand you mean you interpret everything on the copy of the inputs and you run until you either get an ok primitives or you stop on not ok one.
Right, /and/ you stop whenever an attempt is made to write to an object not created during the simulation. So one has to trap primitives new, new: & shallowCopy and collect the results along with the copies of the initial arguments. These objects are safe to write to because they were created as one simulates. Anything else is an error. Could be a nice way to stress runSimulated: :)
Interesting to see if this is useful because runSimulated: is probably at least 100 times slower than executing. An alternative would be to have an execution primitive that entered a special mode that did a GC, installed a page fault handler, advanced the allocation pointer to the next page boundary and then write-protected the entire heap. The error handler would unprotect the entire heap and cause a callback that would raise an exception. So one would run until a write into the heap other than to new space. But this alternative requires lots of VM work and is super tricky. Fingers crossed runSimulated: will work :) cheers Eliot
Stef
Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way.
Just look at the lists and how many methods you find that have been removed years ago...
It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example.
So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation.
best, Eliot
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project