JDK-8035712 : Investigate if RuntimeCallSite linkage can be removed
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u60
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-02-24
  • Updated: 2015-09-29
  • Resolved: 2015-03-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u60 b08Fixed 9Fixed
Related Reports
Duplicate :  
JDK-8010699 - Eventually retire RuntimeNodes
Description
RuntimeCallSites come into play for Runtime nodes where at least on of the arguments is a primitive and one is an Object, previously used to leverage what little static type information that we had. 

We can probably remove all this logic now, in the optimistic world, but we should benchmark without it to make sure that it has no impact. We don't believe it does.

This would hopefully be a drastic simplification of code complexity for very little performance gain. The performance gain would be completely gained by the optimistic architecture anyway,
Comments
Tracking this for 8u60 as we have a regression from removing this for 8u40
04-03-2015
Few notes on the implementation: Since introduction of optimistic typing and static type calculation, compilation of ==, !=, ===, !==, <, <=, >, >= operators was implemented in such a manner that if one of their operands was an object and the other a primitive (int, long, double, boolean), the primitive was boxed, and the generic ScriptRuntime.EQ|NE|STRICT_EQ|STRICT_NE|LT|LE|GT|GE(Object,Object) method was invoked. This turns out to be unnecessary in most cases, as all of the operators are defined such that a comparison of a number to object should instead calculate ToNumber(obj) and compare it to the number. Therefore e.g. (i < o) could be emitted as ((double)i < ToNumber(o)) instead of ScriptRuntime.LT(Integer.valueOf(i), o). In practical terms, we used to invoke the ScriptRuntime.* slow path method when at least one argument's static type was Object. Now it's only invoked when both are (which explains the change from || to && operator in LocalVariableTypesCalculator) Some special cases remained, though: EQ/NE don't compare null as equal to a number, so we couldn't use ToNumber as it converts null to 0; hence instead of calling JSType.toNumber, I added a special new method JSType.toNumberForEq() that converts null to NaN (which compares false to all numbers, including another NaN). Similarly, EQ_STRICT/NE_STRICT are even, well, stricter, so for them we use JSType.toNumberForStrictEq() that converts any non-Number object to NaN by similar reasoning. Finally, benchmarking has shown that our way of implementing LT/GT/LE/GE by having one generic lessThan method is somewhat slow. lessThan explicitly handled some cases for number comparison that were spelled out explicitly in the spec: -0, both Infinities, NaN. Turns out, Java's relational comparison operators already cover all these cases, so a simple comparison suffice. I ended up producing 4 separate methods for all comparison operators, without them delegating to a common worker. They're therefore copy-paste-ish, but they're also fairly small, and they provide a performance boost when implemented like this.
04-03-2015
Deferring to 9, if no one has any concerns that it should be otherwise.
05-11-2014