On 04/02/2009, at 7:27 PM, Ian Rogers wrote:
In this case I was just trying to get to the bottom of the compress
regression and was a bit baffled when it narrowed down to this commit.
What is the compress regression?
RVM-743
Even after reading through the commit I couldn't easily figure out why it
"fixed" the compress regression. It disturbs me when performance changes
significantly for no clear reason, so having some clue as to what's going on
here would be helpful, and I was speculating that that was what Ian may have
been trying to address (which is why I sought clarification).
I've been trying to get the barrier code into shape but no one commit
should have moved performance back. I think the major issue is that
we've had a week or so of misleading performance results from
Habanero.
I think you've misunderstood.
a. There was a documented regression, RVM-743, which goes back to r15240 (a month ago), long before the habanero slowdown (which was at 15301, 5 days ago). r15240 had an unintended effect on space efficiency. You increased the heap size for compress by 1MB (r15255) but that did not fix the OOME's completely, which indicates that the bloat was at least 1MB.
b. The OOME's on compress stopped abruptly with r15318. I started reading through r15318 to work out why it affected RVM-743 and I wondered whether you had been trying to fix RVM-743 in r15318. I was puzzled, so I asked :-) Apparently not.
The issue with the barriers is that the changes amount to a change in an API
which some people rely on heavily, so while it may make sense to change it,
it really should be discussed first.
I thought the MemoryManager API was analogous to RuntimeEntrypoints,
entry points for the compiler and not something that people should be
deliberately coding against.
Those of us who are working with barriers often find ourselves coding against the interface you've changed. I can say this because it happens that I'm doing so right now. It also happens that Daniel and Fil are doing completely unrelated work for new concurrent GC barriers that is also affected by this.
--Steve
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-
http://p.sf.net/sfu/adobe-com_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core