Accessing runtime directly in LibraryCallKit without going through ci
Krystal Mok
rednaxelafx at gmail.com
Wed Jul 9 23:14:43 UTC 2014
Hi John,
Thanks for your comments. I noticed yesterday that I had made a mistake in
the proposed change.
Since that line of code is in Compile::make_vm_intrinsic(), it should be:
if (env()->reflect_CallerSensitive_klass() == NULL) return NULL;
instead of:
if (C->env()->reflect_CallerSensitive_klass() == NULL) return NULL;
Thanks,
Kris
On Wed, Jul 9, 2014 at 4:07 PM, John Rose <john.r.rose at oracle.com> wrote:
> On Jul 3, 2014, at 4:04 PM, Krystal Mok <rednaxelafx at gmail.com> wrote:
>
> Hi everyone,
>
> I just came across this piece of code in C2 LibraryCallKit:
>
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/39bac689e998/src/share/vm/opto/library_call.cpp#l435
>
> 433: case vmIntrinsics::_getCallerClass:
> 434: if (!InlineReflectionGetCallerClass) return NULL;
> 435: if (SystemDictionary::reflect_CallerSensitive_klass() == NULL)
> return NULL;
> 436: break;
>
> Line 435 is accessing the runtime (SystemDictionary) directly without
> going through ci.
> Apparently it runs "okay" in current HotSpot. But as a convention, should
> it be changed to go through ci? i.e.
>
> if (C->env()->reflect_CallerSensitive_klass() == NULL) return NULL;
>
>
> Yes, it should go through the CI. It happens to run OK since it is just a
> null check of a Klass* value, and the GC does not convert null to non-null
> values. (This would be a slight hazard if the value were a compressed
> klass pointer.)
>
> — John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140709/df3f0aba/attachment.html>
More information about the hotspot-compiler-dev
mailing list