RFR: 8195972: Refactor oops in JNI to use the Access API (original) (raw)

Kim Barrett kim.barrett at oracle.com
Thu Mar 29 16:44:31 UTC 2018

On Mar 29, 2018, at 9:54 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:

Hi Kim, On 2018-03-29 01:35, Kim Barrett wrote:

On Mar 28, 2018, at 9:40 AM, Erik Österlund <erik.osterlund at oracle.com> wrote: Even those (temporary) costs could be mitigated if we weren't forced to use the overly generic INCONCURRENTROOT decorator, and could instead provide more precise information to the GC-specific backends (e.g. something like INJNIGLOBALROOT), letting each GC defer its extra barrier work until the changes to get the pause-time benefits are being made. Sure. But I'd like to avoid overly specific decorators that describe the exact root being accessed, rather than its semantic properties, unless there are very compelling reasons to do so.

I understand that. The problems with that are (1) (I think) the semantics are pretty non-obvious to someone not a GC expert, while I thought part of the point of the GC interface (including Access) is to help non-GC folks to write “runtime” code that will correctly interact with the GC, and (2) whether those semantics apply may vary even between GCs that do (some) work concurrently. Maybe we won’t have any really interesting non-temporary cases of the latter? Like I expect this one to be temporary. And maybe there will be very few uses of this decorator, and we’ve already identified (nearly) all of them?

I'd forgotten about jniFastGetField. [,,,] Any idea how important an optimization jniFastGetField might be? How bad would it be to turn it off for ZGC? I have no idea what the cost would be of turning it off. But I feel more compelled to fix it so that we do not have to turn it off. Should not be impossible, but can be done outside of this RFE.

Fixing it should be better. I was just wondering if we have any idea how important these optimizations really are. On the surface they look like they could be fairly important, but...

And there are two other pre-existing uses of INCONCURRENTROOT, both of which seem suspicious to me.

[…] Yes, that sounds like it should be fixed in separate RFEs. Your JNI handle changes look good. Thanks, /Erik

Thanks.

I’ll file those additional RFEs (though maybe there is already one for accessorizing OopHandle). And I will try to get a review of 8199417 done today.

More information about the hotspot-dev mailing list