[rvm-core] ConcMS and MarkCompact collectors
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
[rvm-core] ConcMS and MarkCompact collectors
by David P Grove
::
Rate this Message:
I'd like to suggest we drop these collectors from the sanity runs until they are working a little bit better. Eyeballing recent sanity results, this would get us to the point where the expected results of a full sanity is 100% success (StickImmix also appears to be problematic, but is passing 90/100 which is close enough that removing it doesn't seem to be as justified). |
|
|
Re: [rvm-core] ConcMS and MarkCompact collectors
by Steve Blackburn
::
Rate this Message:
Hi Dave,
On 24/10/2008, at 6:47 AM, David P Grove wrote: > I'd like to suggest we drop these collectors from the sanity runs > until they are working a little bit better. Eyeballing recent sanity > results, this would get us to the point where the expected results > of a full sanity is 100% success (StickImmix also appears to be > problematic, but is passing 90/100 which is close enough that > removing it doesn't seem to be as justified). > Well this depends on what our goal is. Having a baseline of 100% success is very helpful because it allows us to crisply identify failures. I am a big fan of this. On the other hand, arguably we should be testing everything that we believe SHOULD be 100%. I believe ConcMS and MarkCompact are *particularly* important for two reasons: 1) each is the most simple test we have for some very key functionality within the system, and 2) they are canonical collectors by any reasonable definition. Therefore, I'd argue that both of these fall firmly into the camp of things that SHOULD be working at 100% and we should ramp up our efforts to fix them. Daniel is the person to do this, but right now he is at the most critical point in his PhD write-up, so I am loath to put pressure on him to tackle either of these in the short term. There are a number of ways of meeting our objectives: . we could change the definition of sanity and/or introduce new tests . we could ramp up our efforts to fix these things . some other creative solution I don't think we should take any steps which will weaken our resolve to fix these particular problems though. They are important parts of our system and should be working. The cynical interpretation of the above is that if one wants to introduce something new then one should ensure it is not well tested lest it be dropped from the system. Of course I know that position is abhorrent to you. I prefer to keep the bar high with a view to making our system as bullet proof as we can. We then just need to somehow eek out the time to fix the bugs that such testing exposes.... We should also keep a positive frame of mind. Daniel recently brought another family of canonical collector (the reference counters) back from the brink. Cheers, --Steve ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
|
|
Re: [rvm-core] ConcMS and MarkCompact collectors
by David P Grove
::
Rate this Message:
I was mostly making a tactical observation to try to reduce my daily overhead of analyzing the regression runs. As a practical matter, since there are 90+ failures on the sanity run and many of them are intermittent I don't actually try to pay careful attention to those results. I carefully monitor the core and performance test which do have a 100% expected pass rate and immediately notice anything that breaks there. |
|
|
Re: [rvm-core] ConcMS and MarkCompact collectors
by Steve Blackburn
::
Rate this Message:
On 24/10/2008, at 11:23 PM, David P Grove wrote: > I think my concrete suggestion is to pull ConcMS, MarkCompact, and > StickyImmix out of sanity into a new second-tier run that would only > test things that we would like to work someday but actually don't > today. That would give us the nightly failure reminder that things > are broken and also greatly improve the signal-to-noise ratio in the > sanity run. Sounds reasonable to me. --Steve ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
| Free embeddable forum powered by Nabble | Forum Help |
