Anything to do with newObj
- The constant sized bump allocation you mention
- get size ( even variable size for string)
- mem clear if done on a per object basis ( not
really needed with Nursery and RC)
- set object /gc header .
memcpy just very common
any SIMD intrinsic ( unless your generating instructions directly and not
using intrisics)
bounds check
Ben
On Sun, Oct 27, 2013 at 5:01 AM, Jonathan S. Shapiro <[email protected]>wrote:
> The intrinsics that *need* to be inlined (as opposed to procedure calls)
> in my mind are:
>
> - Load and store barriers
> - Constant-sized allocations (for bump allocations)
> - return operations on architectures that do not implement a return
> instruction (which DBT can already catch).
> - stack space check - making sure we have room for a new frame on a
> possibly segmented stack.
>
> The intrinsics that *may *want to be inlined in some cases are:
>
> - GCPoll (mutator thread polling for GC coordination)
>
> I can think of a whole bunch of other communications from the mutator to
> the collector, but I can't think of any that are so performance critical
> that they warrant inlining.
>
> I can also think of a bunch of mechanisms by which the collector
> interrogates the state of a [possibly temporarily] paused mutator, but
> those don't seem likely to involve DBT-style inlining tricks.
>
> Can anybody think of intrinsic[s] that need to be inlined that I haven't
> identified above?
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
