Performance implications of the lambda draft specification

[Marcelo Fukushima]

are these concerns problematic in practice, though? i was under the
impression that almost all the use cases for converting a function to a SAM
would be optimized by hotspot anyway (stack allocation and method inlining),
no?
on the other hand, convertion at compile time seens feasible in the current
(draft) spec, right?

On Fri, Feb 19, 2010 at 2:51 AM, Neal Gafter <neal at gafter.com> wrote:

> An unfortunate consequence of a closures specification/implementation
> would be that it is twice as costly to create as an "equivalent"
> anonymous inner class, and twice as costly to invoke as an
> "equivalent" anonymous inner class.  But that appears to be where the
> specification in its current form is taking us.
>
> The performance costs arise from a number of features of the current
> specification
> (1) The requirement that "this" inside a lambda refers to the lambda
> itself;
> (3) The likelihood of implementing the specification using
> MethodHandle for function types;
> (2) The desire to support SAM classes; and finally
> (4) The lambda conversion as a way of converting a value of function
> type to a SAM type.
>
> The creation cost I'm concerned about is double allocation: first
> allocating an object of the function type, and then allocating an
> object of the SAM type.  The invocation cost I'm concerned about is
> double invocation: the client's invocation of the SAM's method, and
> then the invocation of the function object inside the
> compiler-generated implementation of the SAM.
>
> By contrast, these problems don't arise in BGGA because there is no
> function object (or function type) distinct from the SAM, and the
> lambda conversion occurs at compile-time (not runtime).
>
> Cheers,
> Neal
>
>


-- 
http://mapsdev.blogspot.com/
Marcelo Takeshi Fukushima