Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions on e.g. GC.@preserve #53

Closed
PallHaraldsson opened this issue Oct 6, 2023 · 1 comment
Closed

Questions on e.g. GC.@preserve #53

PallHaraldsson opened this issue Oct 6, 2023 · 1 comment

Comments

@PallHaraldsson
Copy link
Contributor

PallHaraldsson commented Oct 6, 2023

I see GC.@preserve used here (actually also at StaticCompiler.jl in one place), and it's a bit confusing.

It got me thinking, while this package is for use with StaticCompiler, and then not supporting Windows since it doesn't, does it make send to use it without? That might explain if you use with full Julia, its runtime and the GC.

You can use ManualMemory.jl only (or just Libc.malloc) and/or Bumper.jl, so this package doesn't maybe provide much for use with the full runtime. It seems all it has or most at least it to work around the limitations when you don't have the runtime (and then all features).

Another question, you mention threads not supported. You mean Julia's i.e. @threads (for some reason it requires the runtime, not sure it requires GC and that's (only) why). But that's for spawning threads (or at least using already prespawned). It seems to be if you're calling from say C, or Python, and make threads there, then you can call from threads to Julia, also if using these static packages. Can you confirm? I mean then without automatic speedup, i.e. to work on the same problem. But that could potentially also happen some way.

One more, does it also make sense to use this package for GPUCompiler.jl (or is it fully featured already for what applies to GPUs)? Or at least part of the functionality here? I guess excluding all malloc related or related to printing. Maybe that only leaves out e.g. RNGs.

@brenhinkeller
Copy link
Owner

GC.@preserve is actually necessary to get the compiler to not optimize away certain memory references. There's no actual use of the GC involved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants