RFR: 8235669: G1: Stack walking API can expose AS_NO_KEEPALIVE oops

Kim Barrett kim.barrett at oracle.com
Tue Jan 7 02:46:22 UTC 2020


> On Dec 10, 2019, at 11:02 AM, erik.osterlund at oracle.com wrote:
> 
> Hi,
> 
> When the stack is walked and e.g. locals are turned into StackValues, it might be that said local was made a constant oop by the JIT. In such cases, it is read from the nmethod using ON_STRONG_OOP_REF | AS_NO_KEEPALIVE. However, these oops need to be kept alive when concurrent marking is ongoing.
> While I haven't seen crashes obviously linked to this yet, I don't think we should wait until we do, because it certainly will eventually.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8235669
> 
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8235669/webrev.00/
> 
> Thanks,
> /Erik

Change looks good.

I think it's kind of gross that oop_at returns an AS_NO_KEEPALIVE
value to some more or less arbitrary context without any indication
that this can happen.  The scope of AS_NO_KEEPALIVE values really
ought to be more constrained than that.

I wonder if oop_at should do the phantom access, and there should be a
different function for use by those places that want / can cope with
an AS_NO_KEEPALIVE value. So I think there might be some naming / API
issues in this neighborhood, but that can be addressed in a post-14 RFE.




More information about the hotspot-dev mailing list