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

move out Profile from the sysimage #49132

Merged
merged 1 commit into from
Apr 4, 2023
Merged

move out Profile from the sysimage #49132

merged 1 commit into from
Apr 4, 2023

Conversation

KristofferC
Copy link
Sponsor Member

@KristofferC KristofferC commented Mar 24, 2023

Loads fast anyway (edit: a bit slower when adding the precompile stuff):

julia> @time using Profile
  0.008181 seconds (13.36 k allocations: 900.847 KiB)

@IanButterworth
Copy link
Sponsor Member

Profile has stuff precompiled in the repl precompiler

@KristofferC
Copy link
Sponsor Member Author

Why does

repl_script = Profile.precompile_script * repl_script # do larger workloads first for better parallelization

have to run in the REPL?

@IanButterworth
Copy link
Sponsor Member

I guess it doesn't.

@giordano giordano added the stdlib Julia's standard library label Mar 24, 2023
@KristofferC
Copy link
Sponsor Member Author

KristofferC commented Mar 24, 2023

I moved the precompile stuff from generate_precompile to Profile.

@KristofferC
Copy link
Sponsor Member Author

Need to figure out how this will work with the hotkeys for profiling a running application.

@KristofferC KristofferC marked this pull request as draft March 24, 2023 13:45
@IanButterworth
Copy link
Sponsor Member

Need to figure out how this will work with the hotkeys for profiling a running application.

Yeah. It would be great to figure out how to maintain the lack of requirement to explicitly load Profile for the profiling of running code to work.

Options I can see:

  1. Move the Profile.Print functions to c code so it can be called in signals-*.c - It's a lot of code though
  2. Figure out how to load Profile from signals-*.c if it isn't loaded already when a profile is requested
  3. Just require that Profile is loaded first, so people who want the feature need to remember to put it into their startup.jl. This would be a shame IMO.
  4. Just load Profile on startup, even if it's not in the sysimage
    On this PR it's pretty quick!
julia> @time using Profile
  0.077875 seconds (146.53 k allocations: 11.794 MiB)

@KristofferC
Copy link
Sponsor Member Author

Just load Profile on startup, even if it's not in the sysimage. On this PR it's pretty quick!

Well, it is slower than just starting julia itself so I don't think that is an option.

@IanButterworth
Copy link
Sponsor Member

Ok, I found and pushed an alternative fix which is to move the listener into Base and load Profile there when needed

@IanButterworth
Copy link
Sponsor Member

I'm still hitting precompilation

julia> using Profile
[ Info: Precompiling Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]

@KristofferC
Copy link
Sponsor Member Author

I'm still hitting precompilation

It seemed to work for me.

julia> ENV["JULIA_DEBUG"] = "loading";

julia> using Profile
┌ Debug: Rejecting cache file /Users/kristoffercarlsson/.julia/compiled/v1.10/Profile/nGhxz_pvFUp.ji for Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79] since the flags are mismatched
│   current session: use_pkgimages = true, debug_level = 1, check_bounds = 0, inline = true, opt_level = 2
│   cache file:      use_pkgimages = true, debug_level = 1, check_bounds = 1, inline = true, opt_level = 2
└ @ Base loading.jl:2724
┌ Debug: Loading object cache file /Users/kristoffercarlsson/.julia/compiled/v1.10/Profile/nGhxz_ggTXk.dylib for Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]
└ @ Base loading.jl:1010

These files were created by the pkgimage builder make step.

@KristofferC KristofferC marked this pull request as ready for review March 24, 2023 20:40
@IanButterworth
Copy link
Sponsor Member

I didn't cleanall before build. It could be a make issue

@IanButterworth
Copy link
Sponsor Member

IanButterworth commented Mar 25, 2023

Wait, but neither of those cache files are in your julia dir, they're in your depot. Shouldn't they be bundled with Julia?

@KristofferC
Copy link
Sponsor Member Author

I think only when you are making a release they get bundled by setting the depot. But not sure..

@IanButterworth
Copy link
Sponsor Member

After a cleanall build

julia> using Profile
┌ Debug: Rejecting cache file /Users/ian/.julia/compiled/v1.10/Profile/nGhxz_wG2DL.ji because module Core [top-level] is already loaded and incompatible.
└ @ Base loading.jl:2779
[ Info: Precompiling Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]
┌ Debug: Loading object cache file /Users/ian/.julia/compiled/v1.10/Profile/nGhxz_wG2DL.dylib for Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]
└ @ Base loading.jl:1010

Also, all of the stdlib/*.release.image files are zero bytes. Is that expected?

This is intel MacOS if that's relevant

cc. @vchuravy

@vchuravy
Copy link
Sponsor Member

Also, all of the stdlib/*.release.image files are zero bytes. Is that expected?

These are marker files. It's a make technique when you don't know the output file of a rule.

I set JULIA_DEPOT_PATH := $build_prefix/share/julia. Can you check if it contains the files you expected? That should be the same as Sys.STDLIB.

@IanButterworth
Copy link
Sponsor Member

Great. That fixed it

julia> using Profile
┌ Debug: Rejecting cache file /Users/ian/Documents/GitHub/julia/usr/share/julia/compiled/v1.10/Profile/nGhxz_rikHs.ji for Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79] since the flags are mismatched
│   current session: use_pkgimages = true, debug_level = 1, check_bounds = 0, inline = true, opt_level = 2
│   cache file:      use_pkgimages = true, debug_level = 1, check_bounds = 1, inline = true, opt_level = 2
└ @ Base loading.jl:2724
┌ Debug: Loading object cache file /Users/ian/Documents/GitHub/julia/usr/share/julia/compiled/v1.10/Profile/nGhxz_KZhni.dylib for Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]
└ @ Base loading.jl:1010

Very minor but perhaps the check_bounds = 0 image should be built last so it has the latest mtime and is tried first?

@IanButterworth
Copy link
Sponsor Member

Something's not quite right, perhaps with the make setup?

After the last commit and a make cleanall then make I get

julia> using Profile
┌ Debug: Rejecting cache file /Users/ian/.julia/compiled/v1.10/Profile/nGhxz_wG2DL.ji because module Core [top-level] is already loaded and incompatible.
└ @ Base loading.jl:2779
[ Info: Precompiling Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]
┌ Debug: Loading object cache file /Users/ian/.julia/compiled/v1.10/Profile/nGhxz_wG2DL.dylib for Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]
└ @ Base loading.jl:1010

So it's not even trying to find cachefiles in /Users/ian/Documents/GitHub/julia/usr/share/julia/compiled

@vchuravy
Copy link
Sponsor Member

That seems right? We start at the lowest depot and then go up from there? What happens if you remove compiled/Profile?

@IanButterworth
Copy link
Sponsor Member

IanButterworth commented Mar 27, 2023

Oh.. so if it finds something it can't use in a depot, it doesn't search in deeper depots?

@IanButterworth
Copy link
Sponsor Member

IanButterworth commented Mar 27, 2023

That didn't work

julia> using Profile
[ Info: Precompiling Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]
┌ Debug: Loading object cache file /Users/ian/.julia/compiled/v1.10/Profile/nGhxz_wG2DL.dylib for Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]
└ @ Base loading.jl:1010

julia> Base.DEPOT_PATH
3-element Vector{String}:
 "/Users/ian/.julia"
 "/Users/ian/Documents/GitHub/julia/usr/local/share/julia"
 "/Users/ian/Documents/GitHub/julia/usr/share/julia"
% ls /Users/ian/Documents/GitHub/julia/usr/share/julia/compiled/v1.10
DelimitedFiles	SparseArrays

@IanButterworth
Copy link
Sponsor Member

Fixing that missing comma didn't fix it

% make cleanall
...
% make -j6
...
Outputting sysimage file...
Output ──────  60.238698 seconds
    LINK usr/lib/julia/sys.dylib
    JULIA stdlib/SparseArrays.release.image
    JULIA stdlib/DelimitedFiles.release.image
    JULIA stdlib/DelimitedFiles.release.image
    JULIA stdlib/SparseArrays.release.image

% ls /Users/ian/Documents/GitHub/julia/usr/share/julia/compiled/v1.10
DelimitedFiles	SparseArrays

@vchuravy
Copy link
Sponsor Member

Looking at the artifiact from one of the build jobs:

image

@IanButterworth
Copy link
Sponsor Member

Works well for me now. The ctrl-t profile prints quickly

@vchuravy
Copy link
Sponsor Member

Good to go? Or should I move out the Bugfixes into a separate PR?

@IanButterworth
Copy link
Sponsor Member

Or codesigning. It might be that the error happens on the same machine, it's just that locally I only make

@IanButterworth
Copy link
Sponsor Member

Btw, the same checksum failure also happens for the other non-sysimage stdlibs like SparseArrays and they end up being re-precompiled

@IanButterworth
Copy link
Sponsor Member

Ok, so as expected ignoring the checksum failure for pkgimage stdlibs on macos works, so the files are good, just changed somehow.

How can we debug this further?

@IanButterworth
Copy link
Sponsor Member

The mtimes of the dylibs correspond to codesigning, so that must be it.

ian@IanMBP julia-f65df74f4d % ls -lT share/julia/compiled/v1.10/Profile                           
total 14776
-rwxr-xr-x@ 1 ian  staff  3728224 Mar 29 10:22:10 2023 nGhxz_pQJuF.dylib
drwxr-xr-x@ 3 ian  staff       96 Mar 29 10:22:06 2023 nGhxz_pQJuF.dylib.dSYM
-rw-r--r--@ 1 ian  staff    58898 Mar 29 10:22:06 2023 nGhxz_pQJuF.ji
-rwxr-xr-x@ 1 ian  staff  3708096 Mar 29 10:22:10 2023 nGhxz_x4TlO.dylib
drwxr-xr-x@ 3 ian  staff       96 Mar 29 10:22:06 2023 nGhxz_x4TlO.dylib.dSYM
-rw-r--r--@ 1 ian  staff    58898 Mar 29 10:22:06 2023 nGhxz_x4TlO.ji
  | 2023-03-29 10:22:10 EDT | Codesigning /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-macmini-x64-4.0/build/default-macmini-x64-4-0/julialang/julia-master/julia-f65df74f4d/share/julia/compiled/v1.10/Profile/nGhxz_pQJuF.dylib...
  | 2023-03-29 10:22:10 EDT | /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-macmini-x64-4.0/build/default-macmini-x64-4-0/julialang/julia-master/julia-f65df74f4d/share/julia/compiled/v1.10/Profile/nGhxz_pQJuF.dylib: signed Mach-O thin (x86_64) [nGhxz_pQJuF-555549444c4c44cc55553144a1181b3ee2f4af2a]
  | 2023-03-29 10:22:10 EDT | Codesigning /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-macmini-x64-4.0/build/default-macmini-x64-4-0/julialang/julia-master/julia-f65df74f4d/share/julia/compiled/v1.10/Profile/nGhxz_x4TlO.dylib...
  | 2023-03-29 10:22:10 EDT | /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-macmini-x64-4.0/build/default-macmini-x64-4-0/julialang/julia-master/julia-f65df74f4d/share/julia/compiled/v1.10/Profile/nGhxz_x4TlO.dylib: signed Mach-O thin (x86_64) [nGhxz_x4TlO-555549444c4c444a55553144a1e4a5d673f79711]

@staticfloat is it known that codesigning modifies dylibs? If so do we need to just overwrite checksums at the end of the .ji files after codesigning?

@staticfloat
Copy link
Sponsor Member

@staticfloat is it known that codesigning modifies dylibs?

Yes, that's the whole point of codesigning; to modify the dylibs by adding a cryptographic signature to them. I thought the .dylib files would have a hash of the .ji files, not the other way around. Aren't the .dylib files created after the .ji files?

@vchuravy
Copy link
Sponsor Member

The ji contains very little information that the dylibs are dependent on, but we use the ji for quick rejection of cachefiles so we want to be able to detect corruption before we go to load the dylib (which we often can't unload)

@IanButterworth
Copy link
Sponsor Member

Yes, that's the whole point of codesigning

I had thought codesigning saved its information elsewhere

@staticfloat
Copy link
Sponsor Member

I see. Then yes, we need a convenient way to update the checksums inside of the .ji files.

@IanButterworth
Copy link
Sponsor Member

Now that #48545 is merged, this should just work.

Codesigning will still happen for .dmg distribution but that happens after tests and will be handled here JuliaCI/julia-buildkite#292

@IanButterworth
Copy link
Sponsor Member

Now that #48545 is merged, this should just work.

That was wrong, it needed JuliaCI/julia-buildkite#292 which is now merged, so I updated here

Copy link
Sponsor Member

@IanButterworth IanButterworth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be good to go now

@KristofferC KristofferC merged commit b258051 into master Apr 4, 2023
@KristofferC KristofferC deleted the kc/profile_sysimage branch April 4, 2023 04:42
Xnartharax pushed a commit to Xnartharax/julia that referenced this pull request Apr 19, 2023
MilesCranmer added a commit to MilesCranmer/julia-feedstock that referenced this pull request Jun 1, 2023
MilesCranmer added a commit to MilesCranmer/julia-feedstock that referenced this pull request Jun 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stdlib Julia's standard library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants