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