RFR: 8164358: [JVMCI] expose Hotspot intrinsics and HotSpotIntrinsicCandidate info to JVMCI compilers

[John Rose]

On Aug 19, 2016, at 8:39 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> 
>> On 19 Aug 2016, at 17:27, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>> 
>> Is the intent to save space or time?  Interning the strings is another solution that gets all possible sharing.
> 
> The intent is to leverage the naturally repeating symbols (intrinsics for the same class are declared together) to save some space with a trivial trade off in time. We’re already creating about 1800 other strings readConfiguration so doing anything heavier (such as string interning) doesn’t seem worth it.

Another way to do this would be to expose the SID's upward to the Java code,
and expand them to strings only when necessary.  Because there are so many
"common" strings, there is an overhead managing them even for the JVM C code.
That's why we do this:
  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a4faaf753e03/src/share/vm/classfile/vmSymbols.cpp#l73

And this function uses the one long (null-carrying) string to map between SIDs and strings:
  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a4faaf753e03/src/share/vm/classfile/vmSymbols.cpp#l160

If the JVM would pass that same string up to Java, and then use small integer SIDs
when referring to various well-known strings, the amount of eager string creation might
be decreased when the JVMCI is activated.  (Or maybe not.  But it helps with C.)

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160823/8524fbb5/attachment.html>