Giter Site home page Giter Site logo

Comments (3)

amaanq avatar amaanq commented on June 14, 2024

yeah there's no memory leak here, valgrind (with and without massif) report nothing and I don't think DRS is exactly something you can go off of (IF that's what you're looking at, sorry, I was noticing this staying high with DRS but not RSS), since it seems to be very different from what massif and kde's system monitor report to me (these 2 are similar, showing a drop to ~800kb-1.2mb after the calls to free)

I'd like to guess that it's the system either reserving that memory for further reuse for that process, or it could be some other OS-level oddity, not sure

from tree-sitter.

Bruce-Hopkins avatar Bruce-Hopkins commented on June 14, 2024

I managed to track down what the issue I'm seeing is. @amaanq You are right that this is not a memory leak. It seems that the memory is being free, but not released to the OS, which is why memory profilers do not see an issue.

If we change the program to this:

use tree_sitter::{Parser};
use libc;

fn main() {
    let source_code = "fn main() {}\n".repeat(100000).to_string();
    let mut parser = Parser::new();
    parser
        .set_language(tree_sitter_rust::language())
        .expect("Error loading Rust grammar");
    let tree = parser.parse(source_code, None).unwrap();

    drop(tree);
    drop(parser);

    // Release free memory in the heap.
    unsafe {libc::malloc_trim(0);}

    loop {
        // Sleep every 10 miliseconds to prevent high CPU usage
        let ten_millis = std::time::Duration::from_millis(10);
        std::thread::sleep(ten_millis);
        
    }
}

We call malloc_trim to release the memory within the heap. Although far from an ideal solution due to the usage of unsafe code, almost all of the memory gets released to the OS and my System Monitor shows very low memory.

from tree-sitter.

amaanq avatar amaanq commented on June 14, 2024

The default allocator is libc's for tree-sitter, but you can set your own allocator with ts_set_allocator if you prefer something that holds onto memory for reusage less aggressively. You can also avoid pulling in libc for malloc_trim by playing with the env var M_TRIM_THRESHOLD or MALLOC_TRIM_THRESHOLD_ - https://www.gnu.org/software/libc/manual/html_node/Malloc-Tunable-Parameters.html

from tree-sitter.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.