Environment Variables
Julia kann mit einer Reihe von Umgebungsvariablen konfiguriert werden, die entweder auf die übliche Weise für jedes Betriebssystem oder auf eine tragbare Weise innerhalb von Julia festgelegt werden. Angenommen, Sie möchten die Umgebungsvariable JULIA_EDITOR
auf vim
setzen, können Sie ENV["JULIA_EDITOR"] = "vim"
eingeben (zum Beispiel im REPL), um diese Änderung fallweise vorzunehmen, oder dasselbe in die Benutzerkonfigurationsdatei ~/.julia/config/startup.jl
im Home-Verzeichnis des Benutzers hinzufügen, um eine dauerhafte Wirkung zu erzielen. Der aktuelle Wert derselben Umgebungsvariable kann durch die Auswertung von ENV["JULIA_EDITOR"]
bestimmt werden.
Die Umgebungsvariablen, die Julia verwendet, beginnen im Allgemeinen mit JULIA
. Wenn InteractiveUtils.versioninfo
mit dem Schlüsselwort verbose=true
aufgerufen wird, listet die Ausgabe alle definierten Umgebungsvariablen auf, die für Julia relevant sind, einschließlich derjenigen, die JULIA
in ihren Namen enthalten.
Es wird empfohlen, während der Laufzeit keine Umgebungsvariablen zu ändern, wie zum Beispiel in einer ~/.julia/config/startup.jl
.
Ein Grund dafür ist, dass einige Julia-Variablen, wie JULIA_NUM_THREADS
und JULIA_PROJECT
, vor dem Start von Julia gesetzt werden müssen.
Ähnlich werden die __init__()
-Funktionen von Benutzermodulen im sysimage (über PackageCompiler) vor startup.jl
ausgeführt, sodass das Setzen von Umgebungsvariablen in einer startup.jl
möglicherweise zu spät für Benutzercode ist.
Darüber hinaus kann das Ändern von Umgebungsvariablen zur Laufzeit Datenrennen in ansonsten harmlosen Code einführen.
In Bash können Umgebungsvariablen entweder manuell gesetzt werden, indem man z. B. export JULIA_NUM_THREADS=4
vor dem Start von Julia ausführt, oder indem man denselben Befehl zu ~/.bashrc
oder ~/.bash_profile
hinzufügt, um die Variable jedes Mal zu setzen, wenn Bash gestartet wird.
File locations
JULIA_BINDIR
Der absolute Pfad des Verzeichnisses, das die Julia-Ausführungsdatei enthält, setzt die globale Variable Sys.BINDIR
. Wenn $JULIA_BINDIR
nicht gesetzt ist, bestimmt Julia den Wert Sys.BINDIR
zur Laufzeit.
Die ausführbare Datei selbst ist eine von
$JULIA_BINDIR/julia
$JULIA_BINDIR/julia-debug
standardmäßig.
Die globale Variable Base.DATAROOTDIR
bestimmt einen relativen Pfad von Sys.BINDIR
zum Datenverzeichnis, das mit Julia verbunden ist. Dann der Pfad
$JULIA_BINDIR/$DATAROOTDIR/julia/base
bestimmt das Verzeichnis, in dem Julia zunächst nach Quelldateien sucht (über Base.find_source_file()
).
Ebenso bestimmt die globale Variable Base.SYSCONFDIR
einen relativen Pfad zum Verzeichnis der Konfigurationsdateien. Dann sucht Julia nach einer startup.jl
-Datei in
$JULIA_BINDIR/$SYSCONFDIR/julia/startup.jl
$JULIA_BINDIR/../etc/julia/startup.jl
standardmäßig (über Base.load_julia_startup()
).
Zum Beispiel hat eine Linux-Installation mit einer Julia-Ausführungsdatei, die sich unter /bin/julia
befindet, einem DATAROOTDIR
von ../share
und einem SYSCONFDIR
von ../etc
, JULIA_BINDIR
auf /bin
gesetzt, einen Suchpfad für Quell-Dateien von
/share/julia/base
und einen globalen Konfigurationssuchpfad von
/etc/julia/startup.jl
JULIA_PROJECT
Ein Verzeichnispfad, der angibt, welches Projekt das anfängliche aktive Projekt sein sollte. Das Setzen dieser Umgebungsvariable hat denselben Effekt wie die Angabe der --project
Startoption, aber --project
hat eine höhere Priorität. Wenn die Variable auf @.
gesetzt ist (beachten Sie den nachgestellten Punkt), versucht Julia, ein Projektverzeichnis zu finden, das eine Project.toml
oder JuliaProject.toml
Datei aus dem aktuellen Verzeichnis und dessen übergeordneten Verzeichnissen enthält. Siehe auch das Kapitel über Code Loading.
JULIA_PROJECT
muss definiert werden, bevor Julia gestartet wird; es ist zu spät im Startprozess, es in startup.jl
zu definieren.
JULIA_LOAD_PATH
Die JULIA_LOAD_PATH
Umgebungsvariable wird verwendet, um die globale Julia LOAD_PATH
Variable zu befüllen, die bestimmt, welche Pakete über import
und using
geladen werden können (siehe Code Loading).
Im Gegensatz zur Shell-Variable PATH
werden leere Einträge in JULIA_LOAD_PATH
beim Befüllen von LOAD_PATH
auf den Standardwert LOAD_PATH
, ["@", "@v#.#", "@stdlib"]
, erweitert. Dies ermöglicht ein einfaches Anhängen, Voranstellen usw. des Ladepfadwerts in Shell-Skripten, unabhängig davon, ob 4d61726b646f776e2e436f64652822222c20224a554c49415f4c4f41445f504154482229_40726566204a554c49415f4c4f41445f50415448
bereits gesetzt ist oder nicht. Um beispielsweise das Verzeichnis /foo/bar
an LOAD_PATH
voranzustellen, tun Sie einfach
export JULIA_LOAD_PATH="/foo/bar:$JULIA_LOAD_PATH"
Wenn die Umgebungsvariable JULIA_LOAD_PATH
bereits gesetzt ist, wird ihr alter Wert mit /foo/bar
vorangestellt. Andernfalls, wenn 4d61726b646f776e2e436f64652822222c20224a554c49415f4c4f41445f504154482229_40726566204a554c49415f4c4f41445f50415448
nicht gesetzt ist, wird sie auf /foo/bar:
gesetzt, was zu einem LOAD_PATH
-Wert von ["/foo/bar", "@", "@v#.#", "@stdlib"]
expandiert. Wenn 4d61726b646f776e2e436f64652822222c20224a554c49415f4c4f41445f504154482229_40726566204a554c49415f4c4f41445f50415448
auf den leeren String gesetzt ist, expandiert es zu einem leeren LOAD_PATH
-Array. Mit anderen Worten, der leere String wird als ein Array mit null Elementen interpretiert, nicht als ein Array mit einem Element des leeren Strings. Dieses Verhalten wurde gewählt, um es zu ermöglichen, einen leeren Ladepfad über die Umgebungsvariable zu setzen. Wenn Sie den Standardladepfad möchten, setzen Sie entweder die Umgebungsvariable zurück oder, falls sie einen Wert haben muss, setzen Sie sie auf den String :
.
Auf Windows werden Pfadelemente durch das ;
-Zeichen getrennt, wie es bei den meisten Pfadlisten unter Windows der Fall ist. Ersetzen Sie :
durch ;
im obigen Absatz.
JULIA_DEPOT_PATH
Die JULIA_DEPOT_PATH
Umgebungsvariable wird verwendet, um die globale Julia DEPOT_PATH
Variable zu befüllen, die steuert, wo der Paketmanager sowie Julias Code-Lade-Mechanismen nach Paketregistrierungen, installierten Paketen, benannten Umgebungen, Repo-Kopien, zwischengespeicherten kompilierten Paketbildern, Konfigurationsdateien und dem Standardstandort der REPL-Historie-Datei suchen.
Im Gegensatz zur Shell-Variable PATH
, aber ähnlich zu JULIA_LOAD_PATH
, haben leere Einträge in JULIA_DEPOT_PATH
ein spezielles Verhalten:
- Am Ende wird es auf den Standardwert von
DEPOT_PATH
erweitert, ausgenommen das Benutzerdepot. - Zu Beginn wird es auf den Standardwert von
DEPOT_PATH
einschließlich des Benutzerdepots erweitert.
Dies ermöglicht eine einfache Überschreibung des Benutzerdepots, während der Zugriff auf Ressourcen, die mit Julia gebündelt sind, wie Cache-Dateien, Artefakte usw., erhalten bleibt. Um beispielsweise das Benutzerdepot auf /foo/bar
zu wechseln, verwenden Sie ein abschließendes :
.
export JULIA_DEPOT_PATH="/foo/bar:"
Alle Paketoperationen, wie das Klonen von Registrierungen oder das Installieren von Paketen, schreiben jetzt in /foo/bar
. Da der leere Eintrag jedoch auf das Standard-Systemdepot erweitert wird, sind alle gebündelten Ressourcen weiterhin verfügbar. Wenn Sie wirklich nur das Depot unter /foo/bar
verwenden möchten und keine gebündelten Ressourcen laden möchten, setzen Sie einfach die Umgebungsvariable auf /foo/bar
ohne den abschließenden Doppelpunkt.
Um ein Depot am Ende der vollständigen Standardliste hinzuzufügen, einschließlich des Standardbenutzerdepots, verwenden Sie ein führendes :
export JULIA_DEPOT_PATH=":/foo/bar"
Es gibt zwei Ausnahmen von der oben genannten Regel. Erstens, wenn JULIA_DEPOT_PATH
auf den leeren String gesetzt wird, erweitert es sich zu einem leeren DEPOT_PATH
Array. Mit anderen Worten, der leere String wird als ein Array mit null Elementen interpretiert, nicht als ein Array mit einem Element des leeren Strings. Dieses Verhalten wurde gewählt, um es zu ermöglichen, einen leeren Depot-Pfad über die Umgebungsvariable festzulegen.
Zweitens, wenn kein Benutzerdepot in JULIA_DEPOT_PATH
angegeben ist, wird der leere Eintrag auf das Standarddepot einschließlich des Benutzerdepots erweitert. Dies ermöglicht es, das Standarddepot zu verwenden, als ob die Umgebungsvariable nicht gesetzt wäre, indem sie auf den String :
gesetzt wird.
Auf Windows werden Pfadelemente durch das ;
-Zeichen getrennt, wie es bei den meisten Pfadlisten unter Windows der Fall ist. Ersetzen Sie :
durch ;
im obigen Absatz.
JULIA_DEPOT_PATH
muss definiert werden, bevor Julia gestartet wird; es ist zu spät im Startprozess, dies in startup.jl
zu definieren; zu diesem Zeitpunkt können Sie stattdessen direkt das DEPOT_PATH
-Array ändern, das aus der Umgebungsvariable befüllt wird.
JULIA_HISTORY
Der absolute Pfad REPL.find_hist_file()
der Verlaufdatei des REPL. Wenn $JULIA_HISTORY
nicht gesetzt ist, dann wird REPL.find_hist_file()
standardmäßig auf
$(DEPOT_PATH[1])/logs/repl_history.jl
JULIA_MAX_NUM_PRECOMPILE_FILES
Legt die maximale Anzahl verschiedener Instanzen eines einzelnen Pakets fest, die im Precompile-Cache gespeichert werden sollen (Standard = 10).
JULIA_VERBOSE_LINKING
Wenn auf true gesetzt, werden Linker-Befehle während der Vorcompilierung angezeigt.
Pkg.jl
JULIA_CI
Wenn auf true
gesetzt, zeigt dies dem Paketserver an, dass alle Paketoperationen Teil eines Continuous Integration (CI) Systems sind, um Paketnutzungsstatistiken zu sammeln.
JULIA_NUM_PRECOMPILE_TASKS
Die Anzahl der parallelen Aufgaben, die beim Vorcompilieren von Paketen verwendet werden sollen. Siehe Pkg.precompile
.
JULIA_PKG_DEVDIR
Das Standardverzeichnis, das von Pkg.develop
zum Herunterladen von Paketen verwendet wird.
JULIA_PKG_IGNORE_HASHES
Wenn auf 1
gesetzt, ignoriert dies falsche Hashes in Artefakten. Dies sollte mit Vorsicht verwendet werden, da es die Überprüfung von Downloads deaktiviert, aber Probleme beim Verschieben von Dateien zwischen verschiedenen Dateisystemtypen lösen kann. Siehe Pkg.jl issue #2317 für weitere Details.
Dies wird nur in Julia 1.6 und höher unterstützt.
JULIA_PKG_OFFLINE
Wenn auf true
gesetzt, wird der Offline-Modus aktiviert: siehe Pkg.offline
.
Pkg's Offline-Modus erfordert Julia 1.5 oder später.
JULIA_PKG_PRECOMPILE_AUTO
Wenn auf 0
gesetzt, wird die automatische Vorcompilierung durch Paketaktionen, die das Manifest ändern, deaktiviert. Siehe Pkg.precompile
.
JULIA_PKG_SERVER
Gibt die URL des zu verwendenden Paket-Registrierungsdienstes an. Standardmäßig verwendet Pkg
https://pkg.julialang.org
, um Julia-Pakete abzurufen. Darüber hinaus können Sie die Verwendung des PkgServer-Protokolls deaktivieren und stattdessen direkt von ihren Hosts (GitHub, GitLab usw.) auf die Pakete zugreifen, indem Sie festlegen: export JULIA_PKG_SERVER=""
JULIA_PKG_SERVER_REGISTRY_PREFERENCE
Gibt den bevorzugten Registrierungsstil an. Derzeit unterstützte Werte sind conservative
(der Standard), der nur Ressourcen veröffentlicht, die vom Speicherserver verarbeitet wurden (und daher eine höhere Wahrscheinlichkeit haben, von den PkgServers verfügbar zu sein), während eager
Registrierungen veröffentlicht, deren Ressourcen möglicherweise nicht unbedingt von den Speicherservern verarbeitet wurden. Benutzer hinter restriktiven Firewalls, die das Herunterladen von beliebigen Servern nicht zulassen, sollten den eager
Stil nicht verwenden.
Dies betrifft nur Julia 1.7 und höher.
JULIA_PKG_UNPACK_REGISTRY
Wenn auf true
gesetzt, wird das Registry entpackt, anstatt es als komprimiertes Tarball zu speichern.
Dies betrifft nur Julia 1.7 und höher. Frühere Versionen entpacken das Register immer.
JULIA_PKG_USE_CLI_GIT
Wenn auf true
gesetzt, verwenden Pkg-Operationen, die das Git-Protokoll nutzen, ein externes git
-Executable anstelle der standardmäßigen libgit2-Bibliothek.
Die Verwendung des git
-Executables wird nur für Julia 1.7 und höher unterstützt.
JULIA_PKGRESOLVE_ACCURACY
Die Genauigkeit des Paketauflösers. Dies sollte eine positive ganze Zahl sein, der Standardwert ist 1
.
JULIA_PKG_PRESERVE_TIERED_INSTALLED
Ändern Sie die Standardstrategie für die Paketinstallation in Pkg.PRESERVE_TIERED_INSTALLED
, um dem Paketmanager zu ermöglichen, Versionen von Paketen zu installieren, während so viele Versionen von bereits installierten Paketen wie möglich beibehalten werden.
Dies betrifft nur Julia 1.9 und höher.
Network transport
JULIA_NO_VERIFY_HOSTS
JULIA_SSL_NO_VERIFY_HOSTS
JULIA_SSH_NO_VERIFY_HOSTS
JULIA_ALWAYS_VERIFY_HOSTS
Spezifizieren Sie Hosts, deren Identität für bestimmte Transportprotokolle überprüft werden soll oder nicht. Siehe NetworkOptions.verify_host
JULIA_SSL_CA_ROOTS_PATH
Geben Sie die Datei oder das Verzeichnis an, das die Wurzeln der Zertifizierungsstelle enthält. Siehe NetworkOptions.ca_roots
External applications
JULIA_SHELL
Der absolute Pfad der Shell, mit der Julia externe Befehle ausführen sollte (über Base.repl_cmd()
). Standardmäßig wird die Umgebungsvariable $SHELL
verwendet, und es wird auf /bin/sh
zurückgegriffen, wenn $SHELL
nicht gesetzt ist.
Unter Windows wird diese Umgebungsvariable ignoriert, und externe Befehle werden direkt ausgeführt.
JULIA_EDITOR
Der von InteractiveUtils.editor()
zurückgegebene Editor, der z.B. in InteractiveUtils.edit
verwendet wird, bezieht sich auf den Befehl des bevorzugten Editors, zum Beispiel vim
.
$JULIA_EDITOR
hat Vorrang vor $VISUAL
, das wiederum Vorrang vor $EDITOR
hat. Wenn keine dieser Umgebungsvariablen gesetzt ist, wird der Editor unter Windows und OS X als open
betrachtet, oder /etc/alternatives/editor
, falls es existiert, oder emacs
andernfalls.
Um Visual Studio Code unter Windows zu verwenden, setzen Sie $JULIA_EDITOR
auf code.cmd
.
Parallelization
JULIA_CPU_THREADS
Überschreibt die globale Variable Base.Sys.CPU_THREADS
, die Anzahl der verfügbaren logischen CPU-Kerne.
JULIA_WORKER_TIMEOUT
Ein Float64
, der den Wert von Distributed.worker_timeout()
festlegt (Standard: 60.0
). Diese Funktion gibt die Anzahl der Sekunden an, die ein Arbeitsprozess warten wird, bis ein Masterprozess eine Verbindung herstellt, bevor er beendet wird.
JULIA_NUM_THREADS
Eine nicht signierte 64-Bit-Ganzzahl (uint64_t
), die die maximale Anzahl von Threads festlegt, die Julia zur Verfügung stehen. Wenn $JULIA_NUM_THREADS
nicht positiv ist oder nicht gesetzt ist, oder wenn die Anzahl der CPU-Threads nicht durch Systemaufrufe bestimmt werden kann, wird die Anzahl der Threads auf 1
gesetzt.
Wenn $JULIA_NUM_THREADS
auf auto
gesetzt ist, wird die Anzahl der Threads auf die Anzahl der CPU-Threads gesetzt.
JULIA_NUM_THREADS
muss vor dem Start von Julia definiert werden; es ist zu spät im Startprozess, um es in startup.jl
zu definieren.
In Julia 1.5 und höher kann die Anzahl der Threads auch beim Start über das Kommandozeilenargument -t
/--threads
angegeben werden.
Der auto
-Wert für $JULIA_NUM_THREADS
erfordert Julia 1.7 oder höher.
JULIA_THREAD_SLEEP_THRESHOLD
Wenn auf einen String gesetzt, der mit dem nicht groß-/kleinschreibungssensitiven Teilstring "infinite"
beginnt, schlafen die drehenden Threads niemals. Andernfalls wird $JULIA_THREAD_SLEEP_THRESHOLD
als unsigned 64-Bit-Ganzzahl (uint64_t
) interpretiert und gibt in Nanosekunden die Zeit an, nach der drehende Threads schlafen sollten.
JULIA_NUM_GC_THREADS
Legt die Anzahl der Threads fest, die von der Garbage Collection verwendet werden. Wenn nicht angegeben, wird sie auf die Hälfte der Anzahl der Arbeits-Threads gesetzt.
Die Umgebungsvariable wurde in 1.10 hinzugefügt.
JULIA_IMAGE_THREADS
Eine nicht signierte 32-Bit-Ganzzahl, die die Anzahl der Threads festlegt, die bei der Bildkompilierung in diesem Julia-Prozess verwendet werden. Der Wert dieser Variablen kann ignoriert werden, wenn das Modul ein kleines Modul ist. Wenn nicht angegeben, wird der kleinere Wert von JULIA_CPU_THREADS
oder der Hälfte der Anzahl der logischen CPU-Kerne an seiner Stelle verwendet.
JULIA_IMAGE_TIMINGS
Ein boolescher Wert, der bestimmt, ob detaillierte Zeitinformationen während der Bildkompilierung ausgegeben werden. Standardmäßig auf 0.
JULIA_EXCLUSIVE
Wenn auf etwas anderes als 0
gesetzt, dann ist Julias Thread-Politik konsistent mit dem Betrieb auf einer dedizierten Maschine: Der Master-Thread läuft auf Prozessor 0, und die Threads sind affiniert. Andernfalls überlässt Julia dem Betriebssystem die Handhabung der Thread-Politik.
REPL formatting
Umgebungsvariablen, die bestimmen, wie die REPL-Ausgabe im Terminal formatiert werden soll. Im Allgemeinen sollten diese Variablen auf ANSI terminal escape sequences gesetzt werden. Julia bietet eine hochgradige Schnittstelle mit vielen der gleichen Funktionen; siehe den Abschnitt über The Julia REPL.
JULIA_ERROR_COLOR
Die Formatierung Base.error_color()
(Standard: hellrot, "\033[91m"
), die Fehler im Terminal haben sollten.
JULIA_WARN_COLOR
Die Formatierung Base.warn_color()
(Standard: gelb, "\033[93m"
), die Warnungen im Terminal haben sollten.
JULIA_INFO_COLOR
Die Formatierung Base.info_color()
(Standard: cyan, "\033[36m"
), die Informationen im Terminal haben sollten.
JULIA_INPUT_COLOR
Die Formatierung Base.input_color()
(Standard: normal, "\033[0m"
), die die Eingabe im Terminal haben sollte.
JULIA_ANSWER_COLOR
Die Formatierung Base.answer_color()
(Standard: normal, "\033[0m"
), die die Ausgabe im Terminal haben sollte.
System and Package Image Building
JULIA_CPU_TARGET
Ändern Sie die Zielmaschinenarchitektur für (Vor-)Kompilierung system und package images. JULIA_CPU_TARGET
beeinflusst nur die Generierung von Maschinencode-Bildern, die in einem Festplattenspeicher ausgegeben werden. Im Gegensatz zu --cpu-target
oder -C
, command line option, hat es keinen Einfluss auf die Just-in-Time (JIT) Code-Generierung innerhalb einer Julia-Sitzung, wo Maschinencode nur im Speicher gespeichert wird.
Gültige Werte für JULIA_CPU_TARGET
können durch Ausführen von julia -C help
erhalten werden.
Das Setzen von JULIA_CPU_TARGET
ist wichtig für heterogene Rechensysteme, in denen Prozessoren unterschiedlicher Typen oder Merkmale vorhanden sein können. Dies wird häufig in Hochleistungsrechenclustern (HPC) festgestellt, da die Komponenten-Knoten unterschiedliche Prozessoren verwenden können.
Der CPU-Zielstring ist eine Liste von Strings, die durch ;
getrennt sind. Jeder String beginnt mit einem CPU- oder Architektur-Namen und wird gefolgt von einer optionalen Liste von Funktionen, die durch ,
getrennt sind. Ein generic
oder leerer CPU-Name bedeutet das grundlegende erforderliche Funktionsset der Ziel-ISA, das mindestens der Architektur entspricht, mit der die C/C++-Laufzeit kompiliert wurde. Jeder String wird von LLVM interpretiert.
Einige spezielle Funktionen werden unterstützt:
clone_all
Dies zwingt das Ziel, alle Funktionen in sysimg zu klonen. Wenn es in negativer Form verwendet wird (d.h.
-clone_all
), wird das standardmäßig für bestimmte Ziele aktivierte vollständige Klonen deaktiviert.basis([0-9]*)
Dies gibt den (0-basierten) Basiszielindex an. Das Basisziel ist das Ziel, auf dem das aktuelle Ziel basiert, d.h. die Funktionen, die nicht geklont werden, verwenden die Version im Basisziel. Diese Option bewirkt, dass das Basisziel vollständig geklont wird (als ob
clone_all
dafür angegeben ist), wenn es nicht das Standardziel (0) ist. Der Index kann nur kleiner als der aktuelle Index sein.opt_size
Optimieren Sie für die Größe mit minimalen Leistungseinbußen. Clang/GCCs
-Os
.min_size
Optimieren Sie nur für die Größe. Clangs
-Oz
.
Debugging and profiling
JULIA_DEBUG
Aktivieren Sie das Debug-Protokoll für eine Datei oder ein Modul, siehe Logging
für weitere Informationen.
JULIA_PROFILE_PEEK_HEAP_SNAPSHOT
Aktivieren Sie das Sammeln eines Heap-Snapshots während der Ausführung über den Profiling-Peek-Mechanismus. Siehe Triggered During Execution.
JULIA_TIMING_SUBSYSTEMS
Ermöglicht es Ihnen, Zonen für einen bestimmten Julia-Lauf zu aktivieren oder zu deaktivieren. Zum Beispiel wird durch das Setzen der Variablen auf +GC,-INFERENCE
die GC
-Zonen aktiviert und die INFERENCE
-Zonen deaktiviert. Siehe Dynamically Enabling and Disabling Zones.
JULIA_GC_ALLOC_POOL
JULIA_GC_ALLOC_OTHER
JULIA_GC_ALLOC_PRINT
Wenn gesetzt, nehmen diese Umgebungsvariablen Zeichenfolgen an, die optional mit dem Zeichen 'r'
beginnen, gefolgt von einer Zeicheninterpolation einer durch Doppelpunkte getrennten Liste von drei vorzeichenbehafteten 64-Bit-Ganzzahlen (int64_t
). Dieses Triple von Ganzzahlen a:b:c
repräsentiert die arithmetische Folge a
, a + b
, a + 2*b
, ... c
.
- Wenn es das
n
te Mal ist, dassjl_gc_pool_alloc()
aufgerufen wurde, undn
zur arithmetischen Folge gehört, die durch$JULIA_GC_ALLOC_POOL
dargestellt wird, dann wird die Speicherbereinigung erzwungen. - Wenn es das
n
te Mal ist, dassmaybe_collect()
aufgerufen wurde, undn
zur arithmetischen Folge gehört, die durch$JULIA_GC_ALLOC_OTHER
dargestellt wird, dann wird die Speicherbereinigung erzwungen. - Wenn es das
n
te Mal ist, dassjl_gc_collect()
aufgerufen wurde, undn
zur arithmetischen Folge gehört, die durch$JULIA_GC_ALLOC_PRINT
dargestellt wird, dann werden die Zählungen für die Anzahl der Aufrufe vonjl_gc_pool_alloc()
undmaybe_collect()
ausgegeben.
Wenn der Wert der Umgebungsvariable mit dem Zeichen 'r'
beginnt, wird das Intervall zwischen den Garbage-Collection-Ereignissen randomisiert.
Diese Umgebungsvariablen haben nur dann eine Wirkung, wenn Julia mit Debugging für die Speicherbereinigung kompiliert wurde (d. h. wenn WITH_GC_DEBUG_ENV
in der Build-Konfiguration auf 1
gesetzt ist).
JULIA_GC_NO_GENERATIONAL
Wenn auf etwas anderes als 0
gesetzt, führt der Julia-Garbage-Collector niemals "schnelle Durchläufe" des Speichers durch.
Diese Umgebungsvariable hat nur dann eine Wirkung, wenn Julia mit Debugging für die Speicherbereinigung kompiliert wurde (d. h. wenn WITH_GC_DEBUG_ENV
in der Build-Konfiguration auf 1
gesetzt ist).
JULIA_GC_WAIT_FOR_DEBUGGER
Wenn auf etwas anderes als 0
gesetzt, wartet der Julia-Garbage-Collector darauf, dass ein Debugger angehängt wird, anstatt abzubrechen, wenn ein kritischer Fehler auftritt.
Diese Umgebungsvariable hat nur dann eine Wirkung, wenn Julia mit Debugging für die Speicherbereinigung kompiliert wurde (d. h. wenn WITH_GC_DEBUG_ENV
in der Build-Konfiguration auf 1
gesetzt ist).
ENABLE_JITPROFILING
Wenn auf etwas anderes als 0
gesetzt, erstellt der Compiler einen und registriert einen Ereignislistener für die Just-in-Time (JIT) Profilerstellung.
Diese Umgebungsvariable hat nur dann eine Wirkung, wenn Julia mit JIT-Profiling-Unterstützung kompiliert wurde, entweder mit
- Intel's VTune™ Amplifier (
USE_INTEL_JITEVENTS
auf1
in der Build-Konfiguration gesetzt), oder - OProfile (
USE_OPROFILE_JITEVENTS
auf1
in der Build-Konfiguration gesetzt). - Perf (
USE_PERF_JITEVENTS
auf1
in der Build-Konfiguration gesetzt). Diese Integration ist standardmäßig aktiviert.
ENABLE_GDBLISTENER
Wenn auf etwas anderes als 0
gesetzt, aktiviert dies die GDB-Registrierung von Julia-Code in Release-Builds. In Debug-Builds von Julia ist dies immer aktiviert. Es wird empfohlen, dies mit -g 2
zu verwenden.
JULIA_LLVM_ARGS
Argument, die an das LLVM-Backend übergeben werden sollen.
JULIA_FALLBACK_REPL
Zwingt den Fallback-REPL anstelle von REPL.jl.