Java Type Optimization - SAM

A working document describing the state of Project Lambda mentions the so-called SAM types (one abstract method). As far as I know, the current lambda sentence does not affect runtime only by the compiler, making it possible to automatically convert from lambda expressions to these types.

I think in ideal circumstances instances of SAM types can be internally represented by function pointers. Therefore, the JVM can avoid allocating memory for these instances.

I am wondering if modern virtual machines can provide such an optimization.

+7
source share
2 answers

@ Tamás You should probably read this mailing list from Brian Goetz:

http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003877.html

Basically, lambda abstraction is currently implemented using objects. However, it was designed to allow alternative lambda implementations that would be "smaller" than class instances.

You can come up with a situation similar to autoboxing - ints are squared in Integer, but have a "smaller" representation (like ints).

Currently, lambdas should be placed in instances of SAM types, b / c JVM is currently not able to represent lambdas with any smaller construct. There may be a new JVM standard in the future that includes "primitive functions" that can represent lambda as something other than objects.

So, to answer your question, the type of optimization that you offer above may be possible, but it will probably work with post-Java 8 on "primitive functions", and not be implementation specific.

+6
source

There is nothing complicated in converting one class of methods to function pointers, but one thing is missing: lambda expressions are not just functions, but closures . The difference is that closures can capture external variables. Consider the following example in pseudo Java:

public Adder makeAdder(double startNumber) { return #{ int number -> number + startNumber} } ... int startNumber = 5; Adder add5 = makeAdder(startNumber); add5.invoke(4); // ==> 9 

In this example, the lambda function created by calling makeAdder () refers to a variable that was defined outside of this lambda. That's why it is called “closure” - they are “closed” over their free variables (in this case, over startNumber). To cope with such situations, closures must contain both a pointer to a function and a pointer to its environment . Thus, you get some data structure that has a method and at least one variable. But isn't this an object definition in OOP? So, what is the reason for creating a new type of object if you can make it an instance of an anonymous class?

However, some other optimizations for such anonymous classes can be performed. The working document that you pointed out mentions some of them, for example, outputting and using efficient final variables (although this is mainly done to allow lambdas to the JVM in principle, and not to optimize the code). A produced anonymous class can also be finalized, and most JVMs already have good optimization for the final classes and classes.

Other improvements may also concern environmental references - there are many options.

+5
source

All Articles