On 05/04/2013 07:38 PM, Vitaly Davidovich wrote:
Oops, that was my mistake - I thought the lock here was a j.u.c.Lock
which of course doesn't even make sense given we're talking about
ObjectMonitor. So disregard that bit.
Ignoring OOM and continuing just seems very fragile as it means you
somehow know that all state is still consistent. Most java code isn't
async exception safe, so it's hard to reason about state after OOM.
Maybe Reference Handler is OK in that regard though.
I think it is safe to ignore OOME here, since this is the only place
where heap allocation happens and it is known what provokes it.
Otherwise ReferenceHandler just shuffles existing pointers in existing
objects...
Regards, Peter
Cheers
Thanks
Sent from my phone
