[Vm-dev] instability

[Eliot Miranda]

On Mon, Aug 8, 2016 at 2:51 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> Hi Eliot,
> the VMMaker changes relative to LLP64 are so far really tiny: just the
> change of CCodeGenerator for >> and the memcpy.
> I think it's easy enough to revert and test if it changes anything to
> stability.
>
> One bad side of this kind of CCodeGenerator change is that it generates
> thousands of diff preventing any manual review of generated source code
> changes.
> IMO, this should be separated in own commit so that we can bissect.
> More generally, we should generate source in a more atomic fashion (for
> each feature/fix).
> The infrastructure progress (automated tests), and the way to declare a VM
> stable (whatever it is) are there to enable this process.
>
> One possibility would be to use VMMaker branches coupled to git branches
> like I did for LLP64.
> Once we have VM smoke tests + VM simulator tests to improve confidence
> level, you could merge the VMMaker branch with MC, merge the necessary
> platforms changes with git (resolve all *src conflicts as using COG
> branch), regenerate the sources, and commit. I'm pretty sure that a pair of
> MC+git gurus could script that procedure.
>
> If we use such process for each feature, we could integrate several
> features at once, with so called "octopus" merge.
> This would be the process nearest to current one: the integrator (you)
> assemble several features for the next "release" (understand HEAD commit).
> This may raise several questions about rebasing or merging changes, but
> it's worth thinking about it.
>

I'm having difficulty focussing on fixing this problem right now because
the bug means I don't have a stable VM.  I'm trying to a) release machine
code shallowCopy and b) fix a Slang bug (a TSendNode whose receiver is a
Set instead of a member of the TParseNode hierarchy).  So right now I want
to locate a VM that was built before any of the changes that was stable.  I
suppose I could revert my git repository and go from that.  But I'd prefer
to download one.  Things seemed stable in June.  i wonder what revision to
revert to.  I'll take a look.  Bisecting is hard without a reliable test to
crash the program :-(


BTW, somehow I forgot to mark SpurMemoryManager>>markAndTrace: as <inline:
#never> and consequently it is being inlined into markAndTraceStackPage;
not a good idea ;-)  I'll be able to respond more cogently when I feel I
have a stable VM :-/


>
> 2016-08-06 11:00 GMT+02:00 Tobias Pape <Das.Linux at gmx.de>:
>
>>
>>
>> On 06.08.2016, at 08:46, Tim Felgentreff <timfelgentreff at gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > I agree that only reasonably stable code should go into the Cog branch.
>> But  how do we ensure that? I'm against going with someone's "gut feeling"
>> for this, instead I think we really do need some tests. Right now the only
>> "test" we run is that the VM compiles in different configurations on
>> different platforms. We really need proper stress tests, in-Image as well
>> as out-of-Image. There are many tests in Squeak, for example, that have
>> nothing to do with the system and only test VM specifics (that are subject
>> to change anyway, like testing that Floats are boxed). Personally I would
>> think we should move these into the VM project and run them on Travis.
>> Additionally we need an easy way to add a test when a new crash is
>> discovered to guard ourselves against regressions.
>> >
>> > I believe that with more people making contributions (which was one of
>> the reasons for the github move) it just becomes infeasible to always test
>> branches manually.
>>
>> Nothing to add, just what he says.
>>
>> Best regards
>>         -Tobias
>>
>>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160811/54eb2a3a/attachment.htm