10

As of the current JDK 1.8 implementation, it builds an anonymous object to hold the lambda function and calls the function on such object. Is this anonymous object reused in each call, or is an object re-created each time?

Alex Suo
  • 2,977
  • 1
  • 14
  • 22
  • As far as I remember lamdas are not compiled into objects. Instead they are translated into methods of class where they was defined. – mkrakhin Feb 11 '15 at 11:35
  • @mkrakhin http://www.lambdafaq.org/are-lambda-expressions-objects/ – Alex Suo Feb 11 '15 at 12:09
  • I couldn't find a link, but I read an article where was told, that Oracle engineers decided to not implement lambdas as instances of anonymous classes. They told that this approach will affect performance because of additional work for ClassLoaders and additional footprint in meta-space. – mkrakhin Feb 11 '15 at 12:14
  • @mkrakhin AFAIK there is still no byte-code level support to stand alone functions in Java; while compiling this into just the wrapping class raises the problem if you have several lambdas inside the same class. I agree that this would affect class loader performance but I would appreciate if more concrete evidence / detail is presented. – Alex Suo Feb 11 '15 at 12:22
  • I haven't told that they are standalone, they belong to class where they was defined. – mkrakhin Feb 11 '15 at 12:56
  • By the way, I tried to compile simple code http://pastebin.com/LaeLuer4 and I couldn't see any init methods invocations apart from one for Lambda object itself http://pastebin.com/C3j6Chf8 – mkrakhin Feb 11 '15 at 13:09
  • @mkrakhin Yeah, I did the same too. But wanna get a comprehensive idea of the whole scenario, as what I got might well be a compiler optimization for simple cases. – Alex Suo Feb 11 '15 at 13:52

1 Answers1

6

It may be re-used, it may not.

From JLS 15.27.4:

Either a new instance of a class with the properties below is allocated and initialized, or an existing instance of a class with the properties below is referenced.

You cannot depend on it to be one or the other. The compiler and/or runtime can choose the one that will give the best result. (This is one of the benefits of lambdas over anonymous classes -- because every time you use new, even on an anonymous class, it is guaranteed to be a new object, they are unable to optimize it by re-using it, even though 99% of the time you don't care if they are the same object or not.)

In the case where the lambda captures variables from the surrounding scope, it is generally not possible to re-use the object because the value of the captured variables is state stored in the lambda object, and each time the lambda is evaluated (even if it's the same lambda in source code), it may capture different values of the captured variables. Only if the compiler can somehow guarantee that two particular evaluations of the lambda must capture the exact same value of variables, can the compiler re-use the object.

In the case where the lambda does not capture any variables, then all instantiations of that lambda are identical in behavior. So in this case, a single object can be re-used for all evaluations of that lambda. I believe that the current implementation of Java does only allocate one copy for the duration of the program in this case. But this is just an optimization that is implementation-dependent.

newacct
  • 119,665
  • 29
  • 163
  • 224
  • 1. For surrounding scope variable capturing it's generally true for the variables in the method; but I think if its referring the class level variables it should be reusable. 2. Can you give some evidence and/or discuss common implementation and logic about the reusability e.g. Oracle JDK and OpenJDK. I know it can be reused, but it's good to know when and how the byte code compiler or JIT does it. – Alex Suo Feb 12 '15 at 02:18
  • Also do you have documentation link saying this implementation is JVM specific, not a standard? – Alex Suo Feb 12 '15 at 02:20
  • 1
    @AlexSuoL: 1. From a certain point of view, *only* local variables can be "captured". I don't know what you mean by "class level variables". Instance variables are always accessed through member lookup on some reference; if not specified it's implicitly `this`. `this` is effectively a final local variable in all instance methods, and is captured in lambdas just like other local variables, if instance variables or methods are used. `this` can change between different calls to a method, so it needs to be stored just like any other captured local variable. Static variables are not "captured". – newacct Feb 12 '15 at 03:27
  • OK I think it's just a terminology issue of "capture" then :-) – Alex Suo Feb 12 '15 at 03:29
  • @newacct "In the case where the lambda captures variables..." do you also imply that not only a new object created, but a new class constructed? If not, what should happen for a new class to be generated for the same lambda? – Artem Novikov Mar 17 '17 at 20:00
  • @ArtemNovikov: The Java spec doesn't say anything about the class of the object a lambda is evaluated to. But it wouldn't make any sense for instances of the same lambda to be of different classes. Even for anonymous class creation expressions (which lambda expressions can be converted into), all the instances from the same expression are instances of the same class. And the implementation of lambdas is supposed to be more optimized than anonymous classes, so it would be even less likely to have different classes for instances of the same lambda. – newacct Mar 19 '17 at 21:17
  • @newacct actually, the specification makes a precise statement regarding the class: “*Every object produced by evaluation need not belong to the same class (captured local variables might be inlined, for example)*”, even mentioning a scenario where it would make sense (though OpenJDK does not use the opportunity). – Holger Feb 10 '19 at 18:19