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

coroutines memory usage #21481

Open
despiegk opened this issue May 10, 2024 · 4 comments
Open

coroutines memory usage #21481

despiegk opened this issue May 10, 2024 · 4 comments
Labels
Bug This tag is applied to issues which reports bugs. Unit: Memory Management Bugs/feature requests, that are related to the memory management of the compiler.

Comments

@despiegk
Copy link
Contributor

despiegk commented May 10, 2024

Describe the bug

see https://github.com/freeflowuniverse/crystallib/tree/development_alpine/research/coroutines/channels

image

v -o x -cg -enable-globals -use-coroutines run channels4.v

that seems to be an issue

Reproduction Steps

just run channels4.v

Expected Behavior

< 20 MB

Current Behavior

GB mem

Possible Solution

No response

Additional Information/Context

No response

V version

Current V version: V 0.4.5 3835308

Environment details (OS name and version, etc.)

osx

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

@despiegk despiegk added the Bug This tag is applied to issues which reports bugs. label May 10, 2024
@joe-conigliaro
Copy link
Member

I think I see what is happening here, I will report back soon.

@felipensp felipensp added the Unit: Memory Management Bugs/feature requests, that are related to the memory management of the compiler. label May 10, 2024
@joe-conigliaro
Copy link
Member

joe-conigliaro commented May 11, 2024

Hi @despiegk, I have had a look and I see what is happening.

Here you are creating an endless amount of coroutines as the loop never breaks:

	mut t:=Test{}
	mut c:=0
	for {
		c++
		go monitor(ch2,c,mut &t)
		coroutines.sleep(1000 * time.millisecond)
	}

And if we look at the monitor function, it also has a loop which never breaks. This means that the coroutine never finishes, and therefore its stack is never freed.

fn monitor(ch chan string, counter int, mut t &Test) {
	for {
		//println('2 ${m}')
		// coroutines.sleep(1 * time.second)
		t.mycounter += 1
		println('hello from monitor ${counter}')
		coroutines.sleep(100 * time.millisecond)
		println(t)
	
	}
}

Each time a coroutine is created space is allocated on the heap for it's stack. This stack memory is freed when the coroutine finishes. In your code there is an infinite loop, so the coroutine will never finish and it's stack memory will never get freed. Therefore an endless amount of stacks are being allocated and never freed.

I hope this clears things up.

@despiegk
Copy link
Contributor Author

the code I tested with was limited till certain nr of co-routines, and the co-routines are just sleeping and printing something every 5 sec

image

its normal it takes some mem but for only 1000 co-routines 3GB might be much

module main

import coroutines
import time

fn monitor(ch chan string, counter int, mut t &Test) {
	for {
		//println('2 ${m}')
		// coroutines.sleep(1 * time.second)
		t.mycounter += 1
		println('hello from monitor ${counter}')
		coroutines.sleep(5000 * time.millisecond)
		println(t)
	
	}
}

pub struct Test{
pub mut:
	mycounter int
}



fn main() {
	ch1 := chan string{}
	ch2 := chan string{}

	mut t:=Test{}
	mut c:=0
	for i in 0..1000 {
		c++
		go monitor(ch2,c,mut &t)
	}

	coroutines.sleep(4000 * time.second)
}

@joe-conigliaro
Copy link
Member

joe-conigliaro commented May 11, 2024

hi @despiegk, I will have a look with your new example. 3Gb sounds too much for that

EDIT:
Actually 3GB is sounding correct. The current stack size being allocated is 8MB (I think, I am checking this) for every coroutine (I'm seeing if this can be decreased).

However I'm sure you can refactor the code to do what you want with less memory. For example by using less coroutines and re-using each one, something like a worker pool. Or by not having so many coroutines running at once, starting 1000 coroutines is not an issue, its the fact that those 1000 coroutines are never ending, and their memory is never cleaned up. if it was a constant flow of coroutines starting and finishing then the memory footprint would be significantly different.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This tag is applied to issues which reports bugs. Unit: Memory Management Bugs/feature requests, that are related to the memory management of the compiler.
Projects
None yet
Development

No branches or pull requests

3 participants