Author Topic: custom memory allocators and macros versus C++  (Read 1345 times)

Offline silenus

  • BFF
  • ***
  • Posts: 147
    • View Profile
custom memory allocators and macros versus C++
« on: September 20, 2014, 12:56:36 PM »
This might be a bit of a beginners question concerning the implementation of the fluffos driver. But I was looking at some of the code recently and I was somewhat curious what the benefits are of having multiple memory allocation macros in the code are. It would seem to me that the system defaults mainly to sysmalloc these days. Do the  two newer 32 and 64 bit mallocs see much use? and how about the older brk() dependent smalloc? What are the advantages of these nowadays?

It would be nice not to worry if a stl container needs a custom allocator to place nice with the current allocators even if after testing one decides to plug one in to make it compatible with the different variants. Has anyone considered writing a simple mark and sweep garbage collector to replace the ref counting stuff?

Offline FallenTree

  • BFF
  • ***
  • Posts: 476
    • View Profile
Re: custom memory allocators and macros versus C++
« Reply #1 on: September 22, 2014, 12:19:23 AM »
I see little to none value keeping custom malloc implementation around. However some people still use the current 32bit/64bit malloc implementation so I kept those around for the moment, as I deleted most of other implementations in the code base. In the future I want to bundle with google's tcmalloc as the only option for malloc implementations.

mark and sweep garage collector is on the todo list,  but I don't think it's a high-value target. I would rather add circular dependency detection for mapping/array types to make sure they can get deallocated correctly first.

Cheers.

Offline silenus

  • BFF
  • ***
  • Posts: 147
    • View Profile
Re: custom memory allocators and macros versus C++
« Reply #2 on: September 22, 2014, 08:11:54 AM »
I noticed that the current fluffos 3.0 alpha has a slightly different callout.c in it where it uses an stl container for storage. I was thinking about doing some hacking of the callout.c subsystem a while ago and my data structures are a bit different but however share the same property in that they don't place nice with the current xalloc implementation. I was curious if this is important or not. I guess it would mean that the callout subsystem could run the system out of memory withoout the reserve block coming into play. It would seem the way around this might be to use a custom stl allocator that relies on something like xalloc or a rewrite of the whole memory subsystem using a form of garbage collector. I was wondering why you favour a cycle detector. It would seem to me that cycle detection is probably at least close to equally complicated since alot of virtual machine using languages use garbage collection (java,ruby to name two).

How stable is the current 3.0 alpha compared to 2.27? I am curious if it is better to hack the 2.27 or 3.0alpha if I want to get some C++ code working inside fluffos for different subsystems. I consider myself a newbie C/C++ coder so this is sort of a learning for fun project for me for learning to implement new code for standard textbook data structures quickly.

How complicated do you think it would be to slowly retrofit the existing fluffos code with a new llvm jit based compiler? is the code for the compiler phases and bytecode execution mainly in grammar.y trees.c icode.c compiler.c program.c and interpret.c? Some of these files I find quite easy to understand and others a bit difficult at present. trees.c grammar.y and interpret.c seem pretty straightforward to me but I dont currently quite have a grasp on how icode.c compiler.c copes with certain problems in converting lpc to bytecode(I am still not sure how it computes the number of locals per function how it arranges the string share and linearizes the basic blocks and branches into bytecode). I assume I would have to do a bit more reading of the sources and have a slightly better grasp of compiler theory to figure it out completely.

 

Offline FallenTree

  • BFF
  • ***
  • Posts: 476
    • View Profile
Re: custom memory allocators and macros versus C++
« Reply #3 on: September 22, 2014, 03:40:09 PM »
The fluffos 3.0 alpha7 is getting more adoption in chinese mud community,  several major mud has switched to it with no issues.

The reason I haven't bump 3.0 into beta or GA is that I want to finish the driver/lpc runtime code separation / restructure first, which is getting close to finish.  That would be the starting point of integrating more runtime/VM implementation/different language into the driver.

I am also trying adding multi-threading network code in 3.0alpha8, with not very convincing degree of success.

Some more polish work I want to do before 3.0GA , I hope to finish it before 2015. (:-D)