Java - Ottimizzazione tipo SAM

Question

A working document che descrive lo stato di Project Lambda menziona i cosiddetti tipi SAM (metodo astratto singolo). Per quanto ne so, l'attuale proposta lambda non influenza il runtime solo il compilatore rendendo possibile la conversione automatica da espressioni lambda a questi tipi.

Penso che in circostanze ideali le istanze di tipi SAM potrebbero essere rappresentate internamente da puntatori di funzione. Pertanto la JVM potrebbe evitare l'allocazione di memoria per queste istanze.

Mi chiedo se le moderne macchine virtuali siano in grado di fornire tale ottimizzazione.

Answer 1

@ Tamás Probabilmente si dovrebbe avere una lettura di questa mailing list post di Brian Goetz:

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

In sostanza, l'astrazione lambda è attualmente implementato utilizzando oggetti. Tuttavia, è stato progettato per consentire realizzazioni alternative di lambda, che sarebbero "più piccole" rispetto alle istanze di classi.

Si può pensare alla situazione come simile alla funzione di autoboxing: gli interi sono inseriti in numero intero, ma hanno una rappresentazione "più piccola" (come ints).

Attualmente, i lambda devono essere racchiusi nelle istanze di tipi SAM, b/c la JVM attualmente non ha modo di rappresentare un lambda con un costrutto più piccolo. In futuro, potrebbe esserci un nuovo standard JVM che include "funzioni primitive" che potrebbero rappresentare lambda come qualcosa di diverso dagli oggetti.

Quindi, per rispondere alla tua domanda, il tipo di ottimizzazione che proponi sopra, potrebbe essere possibile, ma probabilmente verrebbe con il post-Java 8 su "funzioni primitive" anziché essere una funzione specifica dell'implementazione.

Answer 2

Non c'è niente di difficile nella conversione delle classi di metodo singolo in puntatori di funzioni, ma manca una cosa: le espressioni lambda non sono solo funzioni, sono chiusure . La differenza è che le chiusure possono catturare variabili esterne. Consideriamo ora esempio 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 questo esempio funzione lambda, prodotta dalla chiamata a makeAdder(), si riferisce alla variabile che è stata definita al di fuori di questo lambda. Questo è il motivo per cui si chiamano "chiusure" - sono "chiuse" sulle loro variabili libere (in questo caso - su startNumber). Per gestire tali situazioni, le chiusure devono contenere sia il puntatore a una funzione che il puntatore al suo ambiente . Quindi, ottieni una struttura dati con un metodo e almeno una variabile. Ma non è una definizione di un oggetto in OOP? Quindi qual è la ragione per creare un nuovo tipo di oggetti se puoi renderlo un'istanza di classe anonima?

Tuttavia alcune ottimizzazioni su tali classi anonime possono essere fatte. Il documento di lavoro che hai indicato menziona alcuni di essi, ad esempio, inferendo e utilizzando efficacemente le variabili finali (sebbene ciò avvenga principalmente per consentire lambdas su JVM in principal, non per ottimizzare il codice). Anche la classe anonima prodotta può essere eseguita in modo definitivo e la maggior parte delle JVM ha già buone ottimizzazioni per le classi e le classi finali.

Altri miglioramenti possono riguardare anche i riferimenti all'ambiente - ci sono tonnellate di opzioni lì.