Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make POOL_ALLOCATOR_NEW_DELETE optional #3123

Open
crazydef opened this issue Jan 24, 2023 · 2 comments
Open

Make POOL_ALLOCATOR_NEW_DELETE optional #3123

crazydef opened this issue Jan 24, 2023 · 2 comments
Assignees
@ncesario-lunarg
Labels
enhancement

Comments

@crazydef
Copy link

Without an easy way to disable this macro/these operators, it's very hard to provide a custom memory manager to glslang.

It would be nice if this could be disabled with a build switch.
@ncesario-lunarg
Copy link
Collaborator

I have proposed removing this macro in #3387 in an attempt to make the usage of the pool allocator more obvious in the code.

@ncesario-lunarg ncesario-lunarg self-assigned this Nov 9, 2023
ncesario-lunarg added a commit to ncesario-lunarg/glslang that referenced this issue Dec 9, 2023
@ncesario-lunarg
Make pool allocations more explicit
f04b514 
This removes the ability for some classes to be implicitly allocated
using the pool allocator. Now NewPoolObject should be used to explicitly
allocate any object using the pool allocator.

Some other things this change does:
- Remove some of the NewPool* non-generic functions,
  replacing them with a single "make_unique" style function.
- Existing pointers allocated with the standard allocator are replaced
  with smart pointers.

Related to KhronosGroup#3123.
ncesario-lunarg added a commit to ncesario-lunarg/glslang that referenced this issue Dec 9, 2023
@ncesario-lunarg
Make pool allocations more explicit
70493be 
This removes the ability for some classes to be implicitly allocated
using the pool allocator. Now NewPoolObject should be used to explicitly
allocate any object using the pool allocator.

Some other things this change does:
- Remove some of the NewPool* non-generic functions,
  replacing them with a single "make_unique" style function.
- Existing pointers allocated with the standard allocator are replaced
  with smart pointers.

Related to KhronosGroup#3123.
ncesario-lunarg added a commit to ncesario-lunarg/glslang that referenced this issue Dec 11, 2023
@ncesario-lunarg
Make pool allocations more explicit
2d6da45 
This removes the ability for some classes to be implicitly allocated
using the pool allocator. Now NewPoolObject should be used to explicitly
allocate any object using the pool allocator.

Some other things this change does:
- Remove some of the NewPool* non-generic functions,
  replacing them with a single "make_unique" style function.
- Existing pointers allocated with the standard allocator are replaced
  with smart pointers.

Related to KhronosGroup#3123.
@arcady-lunarg
Copy link
Contributor

The thread pool allocator is used for allocation correctness because of the way the compiler works: while processing a compilation unit, a densely-interlinked object graph is allocated and used to keep track of variables, expressions, types, etc and then when compilation is done it's all deallocated with a single pop() call. In the end the pool allocator delegates to the global operator new[] and operator delete[] for managing the underlying memory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ncesario-lunarg ncesario-lunarg

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@crazydef @ncesario-lunarg @arcady-lunarg