deduplicating lambda methods

B. Blaser bsrbnd at gmail.com
Sun Mar 18 21:02:29 UTC 2018


Well, I'm not disputing your analysis, but let's take the most
frequent *cross-file* (and probably *cross-app*) example [3]:

Runnable r = () -> {};

I think this should be possible to define something like:

diff --git a/src/java.base/share/classes/java/lang/Runnable.java
b/src/java.base/share/classes/java/lang/Runnable.java
--- a/src/java.base/share/classes/java/lang/Runnable.java
+++ b/src/java.base/share/classes/java/lang/Runnable.java
@@ -66,4 +66,5 @@
      * @see     java.lang.Thread#run()
      */
     public abstract void run();
+    public Runnable NOP = () -> {};
 }

and use it within the compiler with some 'getstatic' instead of
multiple 'invokedynamic' (which also might be used directly by
programmers)?

Bernard

[3] http://mail.openjdk.java.net/pipermail/amber-dev/2018-March/002731.html


On 18 March 2018 at 16:43, Brian Goetz <brian.goetz at oracle.com> wrote:
> Clearly that's outside the scope of the current project, so this is all
> speculation.
>
> One of the tradeoffs in attempting to deduplicate across classes is that
> there's a coordination cost.  If class A captures a lambda, and class B
> captures the same lambda, there's some benefit to them doing so
> independently; doing otherwise requires a cache, coordination, lookups,
> locks, etc.  You'd have to show that the hit rate is good enough to make up
> for this.
>
> One place where it likely is -- and we don't currently do this -- is in the
> string concatenation bootstrap.  We currently spin a class for each string
> concatenation site, even though cases like "string and int" are surely
> duplicated many times.  Caching common shapes here is probably a much bigger
> win than caching duplicated lambdas; there is likely to be far more
> duplication.
>
> For the few lambdas and method refs that are out at the "used a million
> times in the same app" end of the spectrum, the winning move there is
> probably some sort of jlink plugin that identifies the most common ones,
> factors them into static final fields of a synthetic class, and replaces
> captures with field references. Doing this in the JDK, though, is probably
> the wrong move, as any list of "famous lambdas" is likely to be wrong for
> 95% of applications, so this is something you want to generate by analysis
> over a specific application.
>
>
>
>
> On 3/18/2018 11:17 AM, B. Blaser wrote:
>>
>> Hi Liam,
>>
>> On 18 March 2018 at 03:04, Liam Miller-Cushon <cushon at google.com> wrote:
>>
>> [...]
>>
>>> The updates to hashing are here:
>>> http://cr.openjdk.java.net/~cushon/lambdadedup/webrev.03/
>>
>> Still looking at the stats [1], we see that the highest duplication
>> frequency of more than 10e3 appears on *cross-file* lambdas but falls
>> to 10e2 on *intra-file* lambdas and your patch suggest an
>> *intra-class* de-duplication with an even lower frequency (note also
>> that the JIT profile issue [2] is still unaddressed)...
>>
>> So, I'm wondering if a set of well defined JIT compliant global shapes
>> (somewhere in 'java.base') would be more efficient in term of class
>> size reduction and performance?
>>
>> Bernard
>>
>> [1]
>> https://drive.google.com/file/d/1abAR_bueU0Zxy4e9XfLVzVe2nwy_POQm/view?usp=sharing
>> [2]
>> http://mail.openjdk.java.net/pipermail/amber-dev/2018-March/002745.html
>
>


More information about the amber-dev mailing list