Request for review(M): 6627983: G1: Bad oop deference during marking
John Rose
john.r.rose at oracle.com
Thu Feb 24 17:27:00 PST 2011
On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote:
> Just by code analysis. Did I miss something?
I felt a slight doubt because there are tricky paths through the various subroutine layers in library_call. I see you converted "must_clear_dest" to "suppress_pre_barrier" along two paths. There's a path through generate_block_arraycopy which *almost* needs the flag also, but it allows the flag to default.
To make the code more obviously correct, I suggest making the flag non-optional in library_call. And when the role of the flag changes, a line or two of code could mark the transition like this:
bool use_pre_barrier = (bt == T_OBJECT); // usual case
if (must_clear_dest) use_pre_barrier = false; // 6627983 suppress pre_barrier, if any
...
foo(..., use_pre_barrier);
If it is simply foo(..., !must_clear_dest), it becomes hard for maintainers to see what the argument means.
In the stub generator the optional boolean is OK as is, although I generally prefer optional booleans to default to 'false'. Given the way the bug is structured, I keep wanting to call it 'suppress_pre_barrier', meaning "just this once, trust me when I tell you not to emit the pre-barrier, if there is one."
-- John
More information about the hotspot-compiler-dev
mailing list