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