Hi All,
on returning to VM work I'm seeing lots of VM crashes with recent changes. It looks like the 4-bit Windows work has really affected things. What to do?
Personally I'd like to see the type inferrence and platform changes reverted and the work put on a fork. But that's just my opinion. Thoughts?
_,,,^..^,,,_ best, Eliot
it is easy to fork a branch in GIT you should do that.
Only stable code (you can decide what that means) should reach the main branch or merged into the Cog Branch.
Git makes it easy to experiment by forking. Don't merge stuff until you can show the branch/commit point is stable.
On Fri, Aug 5, 2016 at 5:40 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
on returning to VM work I'm seeing lots of VM crashes with recentchanges. It looks like the 4-bit Windows work has really affected things. What to do?
Personally I'd like to see the type inferrence and platform changes reverted and the work put on a fork. But that's just my opinion. Thoughts?
_,,,^..^,,,_ best, Eliot
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.
Am 06.08.2016 3:27 vorm. schrieb "John McIntosh" < johnmci@smalltalkconsulting.com>:
it is easy to fork a branch in GIT you should do that.
Only stable code (you can decide what that means) should reach the main branch or merged into the Cog Branch.
Git makes it easy to experiment by forking. Don't merge stuff until you can show the branch/commit point is stable.
On Fri, Aug 5, 2016 at 5:40 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
on returning to VM work I'm seeing lots of VM crashes with recentchanges. It looks like the 4-bit Windows work has really affected things. What to do?
Personally I'd like to see the type inferrence and platform changes reverted and the work put on a fork. But that's just my opinion. Thoughts?
_,,,^..^,,,_ best, Eliot
--
=============== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk ============================================================ ===============
On 06.08.2016, at 08:46, Tim Felgentreff timfelgentreff@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
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.
2016-08-06 11:00 GMT+02:00 Tobias Pape Das.Linux@gmx.de:
On 06.08.2016, at 08:46, Tim Felgentreff timfelgentreff@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
On Mon, Aug 8, 2016 at 2:51 AM, Nicolas Cellier < nicolas.cellier.aka.nice@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@gmx.de:
On 06.08.2016, at 08:46, Tim Felgentreff timfelgentreff@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
Hi Tim,
On Fri, Aug 5, 2016 at 11:46 PM, Tim Felgentreff timfelgentreff@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.
Agreed. We need a suite of tests that is strong enough that we would mark as stable any VM that passed them all.
A simple test is running the test suite, but IME that doesn't stress the VM enough; it does find VM flaws in primitives, etc. But may not stress the system enough to find GC bugs.
One test then is to build a VMMaker image from the updated trunk image (a la image/buildspurtrunkvmmakerimage.sh) and have this image produce all sources (a la [VMMaker generateAllConfigurationsUnderVersionControl] valueSupplyingAnswer: false). All this should happen in three ways: - in a single step, updating the image, loading all of VMMaker and then generating all the sources, - in a single step, but with a save after each step - as three steps, updating the image, saving and quitting, launching, loading all of VMMaker, saving and quitting, launching, generating all sources
This is a good stress case for my usage (and would certainly identify the current instability).
Chris M, could you contribute a Magma multi-image test in any form?
Anyone else have any big stress cases?
Am 06.08.2016 3:27 vorm. schrieb "John McIntosh" < johnmci@smalltalkconsulting.com>:
it is easy to fork a branch in GIT you should do that.
Only stable code (you can decide what that means) should reach the main branch or merged into the Cog Branch.
Git makes it easy to experiment by forking. Don't merge stuff until you can show the branch/commit point is stable.
On Fri, Aug 5, 2016 at 5:40 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
on returning to VM work I'm seeing lots of VM crashes with recentchanges. It looks like the 4-bit Windows work has really affected things. What to do?
Personally I'd like to see the type inferrence and platform changes reverted and the work put on a fork. But that's just my opinion. Thoughts?
_,,,^..^,,,_ best, Eliot
--
=============== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk ============================================================ ===============
On Fri, Aug 12, 2016 at 1:28 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
On Fri, Aug 5, 2016 at 11:46 PM, Tim Felgentreff timfelgentreff@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.
Agreed. We need a suite of tests that is strong enough that we would mark as stable any VM that passed them all.
A simple test is running the test suite, but IME that doesn't stress the VM enough; it does find VM flaws in primitives, etc. But may not stress the system enough to find GC bugs.
One test then is to build a VMMaker image from the updated trunk image (a la image/buildspurtrunkvmmakerimage.sh) and have this image produce all sources (a la [VMMaker generateAllConfigurationsUnderVersionControl] valueSupplyingAnswer: false). All this should happen in three ways:
- in a single step, updating the image, loading all of VMMaker and then generating all the sources,
Would this then be done by Travis? If the sources were generated there, then maybe its a reasonable workflow to generate sources prior to building the VM(??), and have only Travis commit the generated sources prior to building the VM, and then tests that new VM generating sources again.
cheers -ben
- in a single step, but with a save after each step
- as three steps, updating the image, saving and quitting, launching, loading all of VMMaker, saving and quitting, launching, generating all sources
This is a good stress case for my usage (and would certainly identify the current instability).
Chris M, could you contribute a Magma multi-image test in any form?
Anyone else have any big stress cases?
Am 06.08.2016 3:27 vorm. schrieb "John McIntosh" johnmci@smalltalkconsulting.com:
it is easy to fork a branch in GIT you should do that.
Only stable code (you can decide what that means) should reach the main branch or merged into the Cog Branch.
Git makes it easy to experiment by forking. Don't merge stuff until you can show the branch/commit point is stable.
On Fri, Aug 5, 2016 at 5:40 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
on returning to VM work I'm seeing lots of VM crashes with recent changes. It looks like the 4-bit Windows work has really affected things. What to do?Personally I'd like to see the type inferrence and platform changes reverted and the work put on a fork. But that's just my opinion. Thoughts?
_,,,^..^,,,_ best, Eliot
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
-- _,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Eliot Miranda -
John McIntosh -
Nicolas Cellier -
Tim Felgentreff -
Tobias Pape