Vladimir Kotal

If a project is `disabled`, `mirror.py` will exit with 2 thus you can run `sync.py` with `--driveon` to continue past that command.

@ahornace had some idea to store the history in protocol buffers. Another idea would be to use some sort of on disk database (definitely do not want to introduce dependency...

Just to give it a bit more context: I was observing the JVM metrics for history cache creation for the linux-mainline Git repository from scratch index and it looks like...

The history cache creation actually failed to create the XML files and the OOM exception only become visible in the 2nd phase of the indexing: ``` INFO: Creating historycache for...

One idea would be to store history in the index, ideally in a way that would allow traversal without loading the complete history for a file. Might be a way...

The heap memory problems during indexing described in https://github.com/oracle/opengrok/issues/3539#issuecomment-818752840 were largely solved by creating history cache per partes (#3589). There is another problem in the webapp when displaying large history...

I guess one could run the ctags with a tool to track memory leaks (like `libumem.so` + `mdb` on Solaris).

It would be nice if you could run the ctags binaries under the tools described on https://stackoverflow.com/questions/4593191/memory-profiler-for-c , in particular I'd be interested to see the results from Google's tcmalloc...

Also, very likely this is dependent on the input files sent to the `ctags` binaries. Is is possible to tell what are the files leading to increased memory usage ?

Recommended allocators with heap profiling: - https://github.com/gperftools/gperftools - https://github.com/jemalloc/jemalloc