Allocate without GC?

How to allocate classes without GC?

Can you elaborate?

I mean how can I allocate memory without GC? Thus how to create classes, records without GC.

Create…
Do something with class / record / Win API.
Free…

Maybe @ck can elaborate more?

Right but for what purpose? Is this for a low end hardware target? If not, for why avoid the GC?

There are a lot of WinAPI functions where it’s needed to allocate memory. :slight_smile:

Sockets for example etc.

IMHO there should be an option.

I’m open to the option of adding apis to allocate non gc’d heap memory, however I can’t think of any Windows api that needs this. For example anything that returns data (For example: https://msdn.microsoft.com/nl-nl/library/windows/desktop/aa364934(v=vs.85).aspx ) can and should be done with a (Gc’d) byte array. The GC won’t run while this call is active. Blocking sockets should use the same, non blocking sockets where the buffer has to be kept alive should be put in a handle/class of sorts that is used to store this (since you need to keep it alive anyway to know when it’s done sending).

Then atleast please add an option to the RTL so we can recompile it.

Sorry? The RTL is open source on github.

I still don’t see what use cases there are for manual memory management.

Use cases? Delphi compatibility :smiley:

There are currently no plans on provide manual memory management for allocating classes other than maybe for targets where a gc can’t run.

Ugh thats a no go for many delphi devs with existing codebases :wink:
Going from manual management to full GC is no easy task.

We’re of course looking into ways to making porting easier to do, however completely turning off the GC and throwing it out sounds like a bad idea, especially considering the advantages a GC brings. .

What advantages? Performance? I don’t think that GC is faster than manual management.

The advantages of a GC over manual memory management are numerous:

  • It makes for cleaner code, there’s no need to free something, the gc does this
  • No overhead of destructor calls and recursive freeing
  • No need to deal with ownership issues
  • No heap fragmentation (Boehm doesn’t do this, but we’re looking into alternative gc’s that can)
  • Never access an already freed object
  • A concurrent copying gc can actually improve allocation time.

Compared to reference counting:

  • No need for an atomic inc/dec for every assignment (which has noticable overhead)
  • Circular reference aren’t a problem

There are probably many more I forgot about.

Not saying there aren’t disadvantages to garbage collectors, but having done manual, reference counting garbage collection and tracing garbage collection, my preference goes out to a tracing gc.

So how do we recompile the RTL and bypass the GC to only use malloc/free?
It’s not really documented.

This is currently not supported. We might add it in the future but there’s nothing to do this at this moment.

It would involve changing the calls to the GC to an alternative memory allocagor

Btw Delphi RTL has an ARC switch as well so IMHO Oxygene should have the same.
{$IFDEF GC} … {$ENDIF}

Delphi has an arc define. So do we. Same for GC. Switching on the file level is not going to be something we will support.

Too bad!

It makes no real sense. Would be highly confusing if 1 file had GC and the other did mot, especially in the same project.