2015-09-08 21 views
7

Quale sarebbe il modo canonico (se presente, altrimenti alcuno affidabile) di rilevare se il motore JIT è disponibile in modo portatile?Rilevare se JIT è disponibile

Ad esempio, Xamarin.iOS non supporta JIT poiché la piattaforma iOS applica DEP. Mono è abbastanza bravo a colmare il divario interpretando la maggior parte delle cose come espressioni lambda in questi giorni, ma alcune cose non sono (correttamente) implementate, portando a eccezioni di runtime che danneggiano male le prestazioni.

Desidero eseguire questa rilevazione da una libreria di classi portatile condivisa, se possibile.

+1

Hmm, no, non è possibile utilizzare un jitter su iOS perché Apple lo proibisce. Non cercheranno l'app. Cercando di scoprire dettagli specifici di questa piattaforma da una libreria portatile è un non-starter, l'app principale ha bisogno di aiuto. –

+0

Apple vieta di imporre che le pagine scrivibili non siano mai eseguibili (Safari è l'eccezione). Suppongo che sia un altro modo di dirlo :) – Krumelur

risposta

1

Dopo aver scavato nel codice sorgente Mono, sembra che la proprietà "magica" in fase di creazione sia FULL_AOT_RUNTIME. Ad esempio, System.Reflection.Emit.AssemblyBuilder è condizionatamente compilato sulla base di questa proprietà sia impostata, che significa

var canJit = Type.GetType ("System.Reflection.Emit.AssemblyBuilder") != null; 

dovrebbe ottenere me quello che voglio.

2

Si potrebbe provare a eseguire un'operazione che non funzionerà sul codice AoT ma non su JIT (creando un tipo in modo dinamico, ad esempio) e utilizzare un blocco try/catch per definire se JIT è disponibile o meno.

potrebbe essere attuato in questo modo (si noti che questo sarà solo esito negativo quando il linker è impostato su "Link tutte le Assemblee"):

private static bool? _isJITAvailable = null; 
public static bool IsJITAvailable() 
{ 
    if(_isJITAvailable == null) 
    { 
     try 
     { 
      //This crashes on iPhone 
      typeof(GenericClass<>).MakeGenericType(typeof(int)); 
      _isJITAvailable = true; 
     } 
     catch(Exception) 
     { 
      _isJITAvailable = false; 
     } 
    } 

    return _isJITAvailable.Value; 
} 

non vorrei farlo, però. Hai davvero bisogno di quei "callback con rendimento migliore" per cominciare? Questo suona davvero come un'ottica prematura.

+0

Non penso che catturare l'eccezione sia la strada da percorrere poiché può essere letteralmente qualsiasi cosa, 'StackOverflowException', 'OutOfMemoryException' e così via ..,. – Kamo

+0

Il tuo punto è corretto @Kamo. Non ricordo l'eccezione specifica generata da 'MakeGenericType' in questo caso e non ho i mezzi per testarlo adesso, ma aggiornerò la risposta non appena lo faccio –

+0

In questo caso particolare penso che sia' NotSupportedException ':) – Kamo

0

Perché non testare le prestazioni dei due callback in fase di esecuzione?

Se la tua è più lenta della piattaforma, utilizza la piattaforma.
Se la piattaforma è più lenta della tua, usa la tua.

+0

Mi sembra un po 'imbarazzante. La mia soluzione attuale è lasciare che l'app principale indichi questo, che non è del tutto negativo. Volevo solo sapere se c'è una soluzione migliore. – Krumelur

Problemi correlati