-1

In graalvm project, gc is written in java in substratevm. What makes me curious is how to manage the memory of a garbage collector written in a language with gc.

If he manages his own memory by himself, it may cause an infinite loop. Here I assume that the garbage collector includes the functions of memory allocation and recovery, and give an example.

For example: My code is a garbage collector-> I need to create an object and allocate memory-> I called the garbage collector (myself)-> I need to create an object and allocate memory > I called the garbage collector (myself) ......

How does it solve infinite loop problems? My idea is to use a lightweight garbage collector written in an additional local language (like C language) to run itself (garbage collector written in java). Although substratevm seems to be compiled into a local executable binary file in native-image, I think the problem still exists.

983110853
  • 3
  • 1
  • 1
    Option 1: design the garbage collector in a way that it doesn’t need to allocate memory during the garbage collection. Option 2: keep some memory reserved for the garbage collector. Option 3: let the garbage collector run before having no memory left, which is necessary for an efficient copying collector anyway. – Holger Dec 20 '22 at 15:44
  • Please provide enough code so others can better understand or reproduce the problem. – Community Dec 20 '22 at 19:11

1 Answers1

1

SubstrateVM GC is written in a subset of Java that has a few restrictions. One of them is that GC code never allocates memory on the Java heap -- see com.oracle.svm.core.heap.RestrictHeapAccess.NO_ALLOCATION. That makes sense as GC is often started in response to the heap being full, so it would not be able to allocate anything anyway. Instead it requests memory chunks directly from the OS using mmap and the like -- see CommittedMemoryProvider and VirtualMemoryProvider classes

peterz
  • 306
  • 1
  • 3