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

fix: make sure we instantiate non-main modules #93

Merged
merged 11 commits into from
Jan 30, 2025
Merged

Conversation

mhmd-azeez
Copy link
Collaborator

Fixes #92

@mhmd-azeez mhmd-azeez requested review from bhelx and evacchi January 15, 2025 18:04
@mhmd-azeez mhmd-azeez requested a review from zshipko as a code owner January 15, 2025 18:04
@@ -251,8 +254,6 @@ func (p *CompiledPlugin) Instance(ctx context.Context, config PluginInstanceConf
if err != nil {
return nil, fmt.Errorf("failed to initialize Observe Adapter: %v", err)
}

trace.Finish()
Copy link
Collaborator Author

@mhmd-azeez mhmd-azeez Jan 15, 2025

Choose a reason for hiding this comment

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

calling Finish on the trace context right after creating it didn't make sense (we're storing the trace context in the plugin struct), so i removed the call

Copy link
Contributor

Choose a reason for hiding this comment

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

There is also a line:

moduleConfig = moduleConfig.WithName(strconv.Itoa(int(p.instanceCount.Add(1))))

It seems to be redundant now + p.instanceCount also can be removed

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

hmmm, i am not sure, the comment for p.instanceCount suggests otherwise. @evacchi what do you think? I moved the naming closer to the main module initialization to make it clearer that this naming is for the main module

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, you are correct, InstantiateModule comment states that module name can't be reused, this probably also means that other modules can't be instantiated multiple times?

Copy link
Contributor

Choose a reason for hiding this comment

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

IIRC not with the same name, within the same runtime

plugin.go Outdated Show resolved Hide resolved
plugin.go Outdated Show resolved Hide resolved
@mhmd-azeez
Copy link
Collaborator Author

@mymmrac thank you very much for the review!

plugin.go Show resolved Hide resolved
@mhmd-azeez
Copy link
Collaborator Author

@mymmrac i found a way to make module linking work with multiple modules by wrapping the non-main modules in a host module. Can you please test this and see if it works with your use case too?

Copy link
Contributor

@evacchi evacchi left a comment

Choose a reason for hiding this comment

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

holy moly that's actually quite clever 😅 I wonder if there is a perf hit and/or we should allow to opt-in this behavior, but in general it seems like a cool workaround :D

@mhmd-azeez
Copy link
Collaborator Author

@evacchi good point, i will try to run a benchmark on sunday. I was also thinking maybe we implement both? and do one or the other depending if it's necessary. For example, if the user only needs one instance or if they only have one module, we don't need to do any of this (which is probably 90+% of the cases). So if there is a perf hit, we certainly can consider that too

@evacchi
Copy link
Contributor

evacchi commented Jan 24, 2025

yeah that makes sense, we could just make it a flag

Copy link
Contributor

@mymmrac mymmrac left a comment

Choose a reason for hiding this comment

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

LGTM! Very clever solution, it adds a little bit of overhead when calling linked modules, but since it's not very common to have many modules (at list I think so) this is good for our case

Copy link
Contributor

@evacchi evacchi left a comment

Choose a reason for hiding this comment

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

(deleted, see comment in code)

runtime.go Outdated
Comment on lines 25 to 26
func detectGuestRuntime(p *Plugin) guestRuntime {
runtime, ok := haskellRuntime(p, p.mainModule)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the issue with Big Go is that we are really only initializing the main module, dependency are still not being initialized 🤔

Copy link
Contributor

Choose a reason for hiding this comment

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

(working on a patch...)

Copy link
Contributor

Choose a reason for hiding this comment

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

@mhmd-azeez I pushed a commit to this branch (feel free to revert or iterate if you think it's appropriate) with a fix. The issue that I can foresee is that, if there are cross-dependencies between modules, then the init order is random! The "proper" way to init dependencies would be to linearize the dependency graph and then initialize it in that order. We can do that in a follow-up, though!

Copy link
Collaborator Author

@mhmd-azeez mhmd-azeez Jan 30, 2025

Choose a reason for hiding this comment

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

thanks!

Copy link
Contributor

@mymmrac mymmrac left a comment

Choose a reason for hiding this comment

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

Fix for modules compiled with Go 1.24 works, thanks

@mhmd-azeez
Copy link
Collaborator Author

mhmd-azeez commented Jan 30, 2025

The benchmarks don't show a significant difference for the normal case, so I am going to merge the PR and we can schedule any additional work in a new PR

main:

PS D:\dylibso\go-sdk> go.exe test -benchmem -run=^$ -bench ^BenchmarkInitialize$ github.com/extism/go-sdk
goos: windows
goarch: amd64
pkg: github.com/extism/go-sdk
cpu: 13th Gen Intel(R) Core(TM) i7-1365U
BenchmarkInitialize/noop-12                  100          11520235 ns/op         4583576 B/op       7138 allocs/op
PASS
ok      github.com/extism/go-sdk        1.297s
PS D:\dylibso\go-sdk> go.exe test -benchmem -run=^$ -bench ^BenchmarkInitialize$ github.com/extism/go-sdk
goos: windows
goarch: amd64
pkg: github.com/extism/go-sdk
cpu: 13th Gen Intel(R) Core(TM) i7-1365U
BenchmarkInitialize/noop-12                  124          10724696 ns/op         4583436 B/op       7140 allocs/op
PASS
ok      github.com/extism/go-sdk        2.428s
PS D:\dylibso\go-sdk> go.exe test -benchmem -run=^$ -bench ^BenchmarkInitialize$ github.com/extism/go-sdk
goos: windows
goarch: amd64
pkg: github.com/extism/go-sdk
cpu: 13th Gen Intel(R) Core(TM) i7-1365U
BenchmarkInitialize/noop-12                  129           9306463 ns/op         4583531 B/op       7141 allocs/op
PASS
ok      github.com/extism/go-sdk        2.286s
PS D:\dylibso\go-sdk>

fix_module_linking:

PS D:\dylibso\go-sdk> go test ./... -bench=.
ok      github.com/extism/go-sdk        66.679s
PS D:\dylibso\go-sdk> go.exe test -benchmem -run=^$ -bench ^BenchmarkInitialize$ github.com/extism/go-sdk
goos: windows
goarch: amd64
pkg: github.com/extism/go-sdk
cpu: 13th Gen Intel(R) Core(TM) i7-1365U
BenchmarkInitialize/noop-12                  126           9446520 ns/op         4583583 B/op       7143 allocs/op
PASS
ok      github.com/extism/go-sdk        2.258s
PS D:\dylibso\go-sdk> go.exe test -benchmem -run=^$ -bench ^BenchmarkInitialize$ github.com/extism/go-sdk
goos: windows
goarch: amd64
pkg: github.com/extism/go-sdk
cpu: 13th Gen Intel(R) Core(TM) i7-1365U
BenchmarkInitialize/noop-12                  124           9230943 ns/op         4583848 B/op       7148 allocs/op
PASS
ok      github.com/extism/go-sdk        2.262s
PS D:\dylibso\go-sdk> go.exe test -benchmem -run=^$ -bench ^BenchmarkInitialize$ github.com/extism/go-sdk
goos: windows
goarch: amd64
pkg: github.com/extism/go-sdk
cpu: 13th Gen Intel(R) Core(TM) i7-1365U
BenchmarkInitialize/noop-12                  100          12527209 ns/op         4583866 B/op       7144 allocs/op
PASS
ok      github.com/extism/go-sdk        1.408s

@mhmd-azeez mhmd-azeez merged commit 9679867 into main Jan 30, 2025
3 checks passed
@mhmd-azeez mhmd-azeez deleted the fix_module_linking branch January 30, 2025 13:27
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

Successfully merging this pull request may close these issues.

Broken module instantiation
3 participants