[MLton-devel] walking the stack for profiling

[Matthew Fluet]

> 1. I see in x86-mlton-basic.fun that the stack top is
> Classes.GCStateHold.  I assume that this means that the register
> allocator can hold the stack top in a register, which would mean that
> the value in gcState could be wrong.

Correct.  GCStateHold is the portion of the GC state that can be held
and modified in registers (without updating the corresponding memory
location).  You'll notice that
	val farflushClasses = ClassSet.-(nonlivenessClasses, holdClasses)
	val nearflushClasses = ClassSet.-(nonlivenessClasses, holdClasses)
So, I'm never required to flush those locations at near or far transfers.
On the other hand, GCStateHold are in runtimeClasses, so are flushed when
entering or leaving the runtime.

> 2. I see in x86-generate-transfers.fun that when making a nontail call
> the stack top is modified to point at the callee frame before pushing
> the return address, and hence the stack top is pointing at a bogus
> frame (for a very short time).

Yes, I see that too.  Likewise, at a raise, there is a brief moment when
stackTop is pointing to stackBottom (which is a valid stack, but doesn't
give much information).

> Would it be possible to modify the native codegen (with some reorderings
> and flushes and ...) so that gcState.stackTop always points at a
> reasonable stack, without significant performance impact?

I think so.  All of the modifications to stackTop occur in
generate-transfers, and they are almost all under calls to farEntry and
farTransfer; so, forcing a flush of the stackTop in those functions should
cover most of them.  There are a couple of other spots.  As for the times
when it's pointing at the wrong place, we can build the new value in a
temporary and then do the move with the final correct value.

> To be clear about performance, 10% or so is OK, since we can put the
> code under a conditional so that it only affects code being profiled.

I don't think that it will be that expensive.  The simplest solution might
be to put stackTop in GCState class, but that might be more expensive.

I don't have time to work on that today, but I'll try to take a look at it
tomorrow afternoon.  Over the weekend for sure; it should only be a couple
of hours.



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel