Honestly, I never saw an <INVALID OERF> related to a lack of memory.

It typically happens if you do set obj=##class(MyClass).%OpenId(id,,.status)  and do not check for success.

https://cedocs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25Library.Persistent#METHOD_%OpenId

so if you miss if '$isobject(obj)  {  .... error processing  using status....} or similar

then the next access to obj.MyProperty will throw  <INVALID OERF>

Only checking the status will tell you if  you really ran out of memory

If you don't have a similar drive you may need to update %installdir%\cache.cpf

[Journal]
AlternateDirectory=C:\InterSystems\Cache\mgr\journal\
BackupsBeforePurge=2
CurrentDirectory=C:\InterSystems\Cache\mgr\journal\
DaysBeforePurge=2

 

if this isn't enough 

startup Caché in emergency mode as described : 
 https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_secmgmt#GCAS_secmgmt_emerg

and run  DO ^STURECOV from namespace %SYS

it allows you to disable Journal Checking for the next startup.
then restart Caché

I fear there is no such utility by default. 
You may need to do it manually to see if it is a real problem or a side effect from parallel compiling.

I just verify it by multiple runs on CompileAll to be sure.

 [ I'm  just  facing a list of ~100 including deployed classes    crying ] 

If you have private %classes mapped ito %SYS then you have to compile them manually.

compileAll doesn't include %SYS for good reasons. 

My actual solution. Just to complete this.

I'm using ccontainermain as provided by @Dmitry Maslennikov 

 /dur/ccontainermain -xprestart=/dur/dinit -xstop=/dur/dsave/

all scripts are located in my durable volume I connect at container start.

To make life easier all journals and WIJ and also all non-%SYS DBs are also located on durable volume.

It is not foolproof but acceptable for test and development.