runtime: be able to deal with a very small heap
See the comment in the source for details. Also see the discussion in https://github.com/tinygo-org/tinygo/pull/2755, which originally triggered this bug. Somewhat surprising, this results in a slight code size decrease for ARM targets of a few bytes.
Этот коммит содержится в:
		
							родитель
							
								
									9eb4a6268a
								
							
						
					
					
						коммит
						5d177d1328
					
				
					 1 изменённых файлов: 7 добавлений и 0 удалений
				
			
		|  | @ -310,6 +310,13 @@ func alloc(size uintptr, layout unsafe.Pointer) unsafe.Pointer { | |||
| 			index = 0 | ||||
| 			// Reset numFreeBlocks as allocations cannot wrap. | ||||
| 			numFreeBlocks = 0 | ||||
| 			// In rare cases, the initial heap might be so small that there are | ||||
| 			// no blocks at all. In this case, it's better to jump back to the | ||||
| 			// start of the loop and try again, until the GC realizes there is | ||||
| 			// no memory and grows the heap. | ||||
| 			// This can sometimes happen on WebAssembly, where the initial heap | ||||
| 			// is created by whatever is left on the last memory page. | ||||
| 			continue | ||||
| 		} | ||||
| 
 | ||||
| 		// Is the block we're looking at free? | ||||
|  |  | |||
		Загрузка…
	
	Создание таблицы
		
		Сослаться в новой задаче
	
	 Ayke van Laethem
						Ayke van Laethem