[llvm-commits] [llvm] r77706 - in /llvm/trunk: include/llvm/Support/Annotation.h lib/Support/Annotation.cpp

[Dan Gohman]

On Aug 3, 2009, at 10:05 AM, Nicolas Geoffray wrote:
>
>> If the entire rest of the compiler can get away without
>> it, I don't see why vmkit needs to do it.
>>
>
> I can surely use maps for that. My problem is that (a) I haven't  
> coded a
> map implementation where I can control the allocations, and that's  
> very
> important for the runtime. DenseMap and std::map have their own malloc
> allocators (the allocator in stl isn't usable). Using annotations and
> subclassing were easier solutions, timely speaking. And (b) I can't
> avoid a global map, and I hate global maps (needs locking and a global
> allocator). When llvm wants vmkit to materialize a llvm::function, I
> have no way of knowing what is the context of this function. For
> example, a context in Java is a class loader. By being able to attach
> this "context" to annotations or subclasses, there was no need of the
> global map.


What if you put a map member in your ModuleProvider subclass?
That shouldn't require any locking beyond whatever is already
present to protect the Module itself.   Does vmkit assign contexts
to Functions when the Module is created? If so, all of the map's
allocation would happen at the same time, and materializeFunction
calls wouldn't see any additional allocations.

Dan