I'm wondering if there is a way to do a Memory Profiling in a Bud service because I'm

Hey <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url=

V8 isolate is never closed: <div class

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

Memory Profiling a Bud service about bud HOT 5 OPEN

Fuerback commented on May 24, 2024

Memory Profiling a Bud service

from bud.

Comments (5)

Fuerback commented on May 24, 2024 1

Hey @matthewmueller, I'm not experiencing any OOM errors.

I'll share if I find something interesting.

Thanks for the quick answer!

from bud.

matthewmueller commented on May 24, 2024

Hey @Fuerback, thanks for doing this research! I'd say it's still a bit early days for memory optimization in Bud, but I did see rogchap/v8go#367 the other day, which is potentially related.

Are you experiencing out of memory (OOM) errors? It might just build up and then garbage collection triggers after a bit.

If you dig any deeper, please share your findings!

from bud.

dobarx commented on May 24, 2024

V8 isolate is never closed:

bud/package/js/v8/v8.go

Line 17 in bff7b1f

func Eval(path, code string) (string, error) {

from bud.

dobarx commented on May 24, 2024

Also, if reusing isolates, value should be released after Eval. This could also leak memory. New v8go release has:

defer value.Release()

I've had a similar problem on experiment side project where I tried to write simpler svelte renderer in Go. I wanted to reuse isolates for better performance. But memory usage would just spike up since rendered html would not get cleared from memory.

Now I tried adding value.Release() and it seems it solved this issue.

from bud.

matthewmueller commented on May 24, 2024

@dobarx, thanks for your research!

Right now we are re-using the isolates and context for the duration of the running process, but they do get cleaned up on close:

bud/package/js/v8/v8.go

Lines 133 to 138 in bff7b1f

 func (vm *VM) Close() error { 

 vm.context.Close() 

 vm.isolate.TerminateExecution() 

 vm.isolate.Dispose() 

 return nil 

 }

This feels like the right approach so only need to load these svelte templates once, then when rendering HTML, it's just calling those functions over and over again. I haven't had the time to do any more in-depth research on this topic yet.

FWIW, my thinking around keeping context around is that since we're running developer-controlled scripts, we're not concerned about security issues that would otherwise crop up from user-run scripts. It's a bit faster too IIRC.

You are right that we aren't currently releasing the value:

bud/package/js/v8/v8.go

Lines 113 to 131 in bff7b1f

 func (vm *VM) Eval(path, expr string) (string, error) { 

 value, err := vm.context.RunScript(expr, path) 

 if err != nil { 

 return "", err 

 } 

 // Handle promises 

 if value.IsPromise() { 

 prom, err := value.AsPromise() 

 if err != nil { 

 return "", err 

 } 

 // TODO: this could run forever 

 for prom.State() == v8go.Pending { 

 continue 

 } 

 return prom.Result().String(), nil 

 } 

 return value.String(), nil 

 }

value.Release(), does seem promising.

from bud.

Memory Profiling a Bud service about bud HOT 5 OPEN

Comments (5)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	func (vm *VM) Close() error {
	vm.context.Close()
	vm.isolate.TerminateExecution()
	vm.isolate.Dispose()
	return nil
	}

	func (vm *VM) Eval(path, expr string) (string, error) {
	value, err := vm.context.RunScript(expr, path)
	if err != nil {
	return "", err
	}
	// Handle promises
	if value.IsPromise() {
	prom, err := value.AsPromise()
	if err != nil {
	return "", err
	}
	// TODO: this could run forever
	for prom.State() == v8go.Pending {
	continue
	}
	return prom.Result().String(), nil
	}
	return value.String(), nil
	}