Hi Ian and Than, Thank you both.
Does it use the data available on *__LLVM_STACKMAPS* section to create that specific stack map? Or does it follow a different way to generate stack map information? Thank you, Kavindu On Monday, 12 July 2021 at 18:25:22 UTC+5:30 th...@google.com wrote: > >Also does gollvm create a new stack map? I think it does not use the > stack map created by LLVM. > > gollvm does not use stack maps of the format used by LLVM, correct. > > Than > > > On Fri, Jul 9, 2021 at 11:17 AM Kavindu Gimhan Zoysa <kavin...@gmail.com> > wrote: > >> Also does gollvm create a new stack map? I think it does not use the stack >> map >> <https://releases.llvm.org/11.0.1/docs/StackMaps.html#stackmap-format> >> created by LLVM. >> >> Thank you, >> Kavindu >> On Friday, 9 July 2021 at 19:35:03 UTC+5:30 Kavindu Gimhan Zoysa wrote: >> >>> Thank you Than, Is go scheduler is responsible for running GC? >>> >>> On Friday, 9 July 2021 at 19:14:43 UTC+5:30 th...@google.com wrote: >>> >>>> >1. If we do not enable the gc (-enable-gc=1), GC assumes all the stack >>>> memory blocks are pointed to the heap. >>>> >2. If gc is enabled, it inserts statepoints and generates the stack >>>> map (by LLVM). Using that stack map, GC can find where the actual heap >>>> references are located. >>>> >>>> Yes, this is basically correct. >>>> >>>> >>>> >As per my understanding, GC is common for both cases (still I was >>>> unbale to find the source code for this GC). >>>> >>>> The GC is located in the Go runtime, the version incorporated into >>>> libgo in gofrontend. See >>>> >>>> >>>> https://go.googlesource.com/gofrontend/+/01cb2b5e69a2d08ef3cc1ea023c22ed9b79f5114/libgo/go/runtime/mgc.go >>>> >>>> Cheers, Than >>>> >>>> On Fri, Jul 9, 2021 at 9:16 AM Kavindu Gimhan Zoysa <kavin...@gmail.com> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> By looking at the source code, and other mail theads in group, I was >>>>> able to understand the sopport of GC by gollvm upto some extend. >>>>> >>>>> 1. If we do not enable the gc (-enable-gc=1), GC assumes all the stack >>>>> memory blocks are pointed to the heap. >>>>> 2. If gc is enabled, it inserts statepoints and generates the stack >>>>> map (by LLVM). Using that stack map, GC can find where the actual heap >>>>> references are located. >>>>> >>>>> As per my understanding, GC is common for both cases (still I was >>>>> unbale to find the source code for this GC). >>>>> >>>>> I really appreciate if you can correct me if I am wrong. >>>>> >>>>> Thank you, >>>>> Kavindu >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "golang-nuts" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to golang-nuts...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/golang-nuts/c57dfdf2-dfc4-4f81-b432-739165065d87n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/golang-nuts/c57dfdf2-dfc4-4f81-b432-739165065d87n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/44fea268-5afa-4dab-869b-414deac6ebe4n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/44fea268-5afa-4dab-869b-414deac6ebe4n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9f9cf89c-134e-48a8-a2b7-d167a06e770fn%40googlegroups.com.
