JDK-8015419 : given a call with boxed operands, explore possible callers for evidence of unboxed use of the operand
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-05-25
  • Updated: 2018-10-05
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.
Other
tbdUnresolved
Related Reports
Relates :  
Description
For example, given this static method:

void logIf(boolean flag, Supplier<String> message) {
  if (flag)  System.out.println(message.get());
}

and this use:

invokedynamic{ new Supplier(){ public String get() { return "it's late"; } } }

We notice in this case that if the flag is usually false then we can delay building the anonymous class instance (under Supplier).

After inlining, the steps become clear.
* an inner class construction call
* initialization into the object (as into a box) of all relevant environmental values
* inlined invocation of logIf(false, ���)
* the closure is not created
* inlined inaction of logIf(true, ���)
* the closure is still not created, at least until it need to escapes as a normal object
* in normal operation, the box does not really exist 

One bit of strategy is important:  Make methods more attractive to inline if they operate on their operands.  Getting the operand creation into the same scope as the final operation leads to many code simplifications.