Is this a bug?

[Andrew Dinn]

On 29/05/12 17:52, Andrew Haley wrote:
> Here in Thumb2_Return I see:
> 
> void Thumb2_Return(Thumb2_Info *jinfo, unsigned opcode, int bci, int stackdepth)
> {
> ...
>   if (jinfo->method->is_synchronized()) {
>     unsigned loc_success1, loc_success2, loc_failed, loc_retry, loc_exception;
>     unsigned loc_illegal_monitor_state;
>     Thumb2_Flush(jinfo);
> //    Thumb2_save_locals(jinfo);
> 
> I'm wondering if Thumb2_save_locals should be commented out because if
> we hit a safepoint we'll be processing stale versions of locals.  Is
> that potentially a bug, or not?  I think it might be, because there
> might be a new version of a local that gets missed.  But so what?  If
> it only exists as a local, and the frame is about to be dropped, it
> doesn't matter, it's unreachable anyway.  The GC will process stale
> versions of the locals, which might mean that some old objects will be
> kept alive for longer than they should, but that doesn't really
> matter.
> 
> Is there any reason to save locals at a return statement, then?
> I think not, but it doesn't feel right to have the GC scanning
> stale data.  Thoughts?

No, it is definitely not a bug. At return there is no need to preserve
any current references by writing them back. If the GC fails to retain
the referenced object because it was not written back then no matter
because nothing will ever try to use the reference. In fact, in such a
situation when you to write back the only extant reference from a
register to the stack this is going to keep the referenced object alive
unnecessarily for another GC cycle.

Contrariwise, if you don't save locals you may leave an out of date
reference on the stack which is the only extant reference to an object
and, as a consequence, cause the referenced object to survive another GC
cycle. But that is not a significant problem because it will get GCed on
the next cycle -- nothing says you have to GC objects quickly. Of course
in this case, writing back might possibly replace that stale reference
with a different reference which avoids retention of the dead object.
But then again, it might not. The argument for writing back in this case
assumes the in-register reference written back over the stale one is
live by virtue of some other occurrence --if not then you are back to
the previous case.

Since writing back does not have a predictable outcome in either case
and since in both cases the chance of prolonging an object life is
likely to be low I would recommend not saving locals. At least you know
this will avoid work.

regards,


Andrew Dinn
-----------