precision

--===============0133196479==
Content-Type: multipart/alternative; boundary=001a11c3bdb4d8fde204f7b3a881

--001a11c3bdb4d8fde204f7b3a881
Content-Type: text/plain; charset=UTF-8

I have been coding C++ for many years. Recently i learned functional
programming, and i would like to use it more as it feels like a new world
of free mind after C++.

But FP needs GC. As still a C++ guy, i carefully researched the resource
consumption GC involves. It surprised me that most GC implementations are
not precise.

As i understood: there are too limitations in stack marking:
1) last managed frame,
2) native frames.

1 seems to be solvable by the shadow stack technique, which is simple and
seems easy to implement. The speed penalty seems acceptable or at least
acceptable in many use cases. Runtimes accept the overhead of array bounds
checks, null reference checks, GC, ... to be more reliable and less buggy
than C++, many runtimes also lack generics monomorphisation  - so why not
accept yet another source of speed decrease?

2 seems to be avoidable by giving the user the responsibility to not pass
managed pointers to native functions.

So it seems to be possible to achieve full precision at least as a
non-default option of the GC.

I looked at many GC implementations, most of them do not even mention this
problem. Mono GC is nice exception, as there is detailed documentation
about it.

I send this mail for 2 goals.
1) I may miss something in this topic. I ask for a theoretical education
about why the problem of precision is so neglected by everyone?
2) I ask to implement full GC precision as an option.

Thank you

--001a11c3bdb4d8fde204f7b3a881
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have been coding C++ for many years. Recently i learned =
functional programming, and i would like to use it more as it feels like a =
new world of free mind after C++.=C2=A0<div><br></div><div>But FP needs GC.=
 As still a C++ guy, i carefully researched the resource consumption GC inv=
olves. It surprised me that most GC implementations are not precise.=C2=A0<=
div>
<br></div><div>As i understood: there are too limitations in stack marking:=
=C2=A0</div><div>1) last managed frame,=C2=A0</div><div>2) native frames.=
=C2=A0</div><div><br></div><div>1 seems to be solvable by the shadow stack =
technique, which is simple and seems easy to implement. The speed penalty s=
eems acceptable or at least acceptable in many use cases. Runtimes accept t=
he overhead of array bounds checks, null reference checks, GC, ... to be mo=
re reliable and less buggy than C++, many runtimes also lack generics monom=
orphisation =C2=A0- so why not accept yet another source of speed decrease?=
=C2=A0</div>
<div><br></div><div>2 seems to be avoidable by giving the user the responsi=
bility to not pass managed pointers to native functions.<br><br>So it seems=
 to be possible to achieve full precision at least as a non-default option =
of the GC.</div>
<div><br></div><div>I looked at many GC implementations, most of them do no=
t even mention this problem. Mono GC is nice exception, as there is detaile=
d documentation about it.</div><div><br></div><div>I send this mail for 2 g=
oals.=C2=A0</div>
<div>1) I may miss something in this topic. I ask for a theoretical educati=
on about why the problem of precision is so neglected by everyone?</div><di=
v>2) I ask to implement full GC precision as an option.</div><div><br></div=
>
<div>Thank you</div><div><br></div><div><br></div></div></div>

--001a11c3bdb4d8fde204f7b3a881--

--===============0133196479==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Mono-gc-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-gc-list

--===============0133196479==--