I wonder if instead of combining region-based MM with GC (as is currently
done in MLKit) it would be possible to combine region-based MM with linear
types in ATS to achieve ideal memory control.
No, I have not considered region-based memory management for ATS.
I have a very simplistic view on memory management. My first choice is
alway GC. If GC becomes a serious problem, then I choose manual memory
management.
It is not easy to tell when one should choose region-based memory management
over GC.On Monday, March 3, 2014 3:22:49 PM UTC-5, H Zhang wrote:
I wonder if instead of combining region-based MM with GC (as is currently
done in MLKit) it would be possible to combine region-based MM with linear
types in ATS to achieve ideal memory control.
But the ATS/C code can use manual allocation/deallocation.On Friday, March 14, 2014 12:52:10 AM UTC-4, H Zhang wrote:
My argument isn’t that GC is bad but that multiple GCs are not compatible
with each other. BWD is too generic, does not take advantage of language
specific characteristics, is stop-the-world etc. If you look at Lua,
Python, Scheme, Prolog, various MLs …, they all implement their own GC
strategies. That makes it hard to link C code that uses BWD (malloc/free
type) GC with those run-times (not that I have much experience doing that,
just that there is a lack of evidence that will work). If you target JVM or
CLR then sure GC is not a problem, but the attraction of using ATS is also
diminished. Maybe when there are enough language implementations that can
target LLVM, GC compatibility will no longer be a problem?
Haitao
On Thursday, March 13, 2014 8:11:57 PM UTC-7, gmhwxi wrote:
Even if one can use ML without using GC, it is still not easy to justify
why
one wants to do it. I would like to see a compelling case for it.
On Thursday, March 13, 2014 10:21:27 PM UTC-4, H Zhang wrote:
MLKit seems to have made good progress on this. But if your target is
for people who want to program in ML and run a ML top level this may not be
worth all the effort. But if you want to use ML to write a library or
extension where GC is undesirable this could make a big difference.
Thanks for the BitC reference. I will check it out.
Haitao
On Thursday, March 13, 2014 4:28:13 PM UTC-7, Raoul Duke wrote:
The BitC folks have been kicking around ideas about manual vs. region
vs. gc management. Can’t say I have a good link to it tho. http://www.coyotos.org/pipermail/bitc-dev/
Seems to me, tho I’m not well versed, like region stuff is a little
pie-in-the-sky still???
MLKit seems to have made good progress on this. But if your target is for
people who want to program in ML and run a ML top level this may not be
worth all the effort. But if you want to use ML to write a library or
extension where GC is undesirable this could make a big difference.
Thanks for the BitC reference. I will check it out.
HaitaoOn Thursday, March 13, 2014 4:28:13 PM UTC-7, Raoul Duke wrote:
The BitC folks have been kicking around ideas about manual vs. region vs.
gc management. Can’t say I have a good link to it tho. http://www.coyotos.org/pipermail/bitc-dev/
Seems to me, tho I’m not well versed, like region stuff is a little
pie-in-the-sky still???
My argument isn’t that GC is bad but that multiple GCs are not compatible
with each other. BWD is too generic, does not take advantage of language
specific characteristics, is stop-the-world etc. If you look at Lua,
Python, Scheme, Prolog, various MLs …, they all implement their own GC
strategies. That makes it hard to link C code that uses BWD (malloc/free
type) GC with those run-times (not that I have much experience doing that,
just that there is a lack of evidence that will work). If you target JVM or
CLR then sure GC is not a problem, but the attraction of using ATS is also
diminished. Maybe when there are enough language implementations that can
target LLVM, GC compatibility will no longer be a problem?
HaitaoOn Thursday, March 13, 2014 8:11:57 PM UTC-7, gmhwxi wrote:
Even if one can use ML without using GC, it is still not easy to justify
why
one wants to do it. I would like to see a compelling case for it.
On Thursday, March 13, 2014 10:21:27 PM UTC-4, H Zhang wrote:
MLKit seems to have made good progress on this. But if your target is for
people who want to program in ML and run a ML top level this may not be
worth all the effort. But if you want to use ML to write a library or
extension where GC is undesirable this could make a big difference.
Thanks for the BitC reference. I will check it out.
Haitao
On Thursday, March 13, 2014 4:28:13 PM UTC-7, Raoul Duke wrote:
The BitC folks have been kicking around ideas about manual vs. region
vs. gc management. Can’t say I have a good link to it tho. http://www.coyotos.org/pipermail/bitc-dev/
Seems to me, tho I’m not well versed, like region stuff is a little
pie-in-the-sky still???
Right. And running a separate heap for ATS would remove the burden of
worrying about occasionally using non-linear structures.On Thursday, March 13, 2014 10:01:57 PM UTC-7, gmhwxi wrote:
Running two GC’s is unlikely to work.
But the ATS/C code can use manual allocation/deallocation.
On Friday, March 14, 2014 12:52:10 AM UTC-4, H Zhang wrote:
My argument isn’t that GC is bad but that multiple GCs are not compatible
with each other. BWD is too generic, does not take advantage of language
specific characteristics, is stop-the-world etc. If you look at Lua,
Python, Scheme, Prolog, various MLs …, they all implement their own GC
strategies. That makes it hard to link C code that uses BWD (malloc/free
type) GC with those run-times (not that I have much experience doing that,
just that there is a lack of evidence that will work). If you target JVM or
CLR then sure GC is not a problem, but the attraction of using ATS is also
diminished. Maybe when there are enough language implementations that can
target LLVM, GC compatibility will no longer be a problem?
Haitao
On Thursday, March 13, 2014 8:11:57 PM UTC-7, gmhwxi wrote:
Even if one can use ML without using GC, it is still not easy to justify
why
one wants to do it. I would like to see a compelling case for it.
On Thursday, March 13, 2014 10:21:27 PM UTC-4, H Zhang wrote:
MLKit seems to have made good progress on this. But if your target is
for people who want to program in ML and run a ML top level this may not be
worth all the effort. But if you want to use ML to write a library or
extension where GC is undesirable this could make a big difference.
Thanks for the BitC reference. I will check it out.
Haitao
On Thursday, March 13, 2014 4:28:13 PM UTC-7, Raoul Duke wrote:
The BitC folks have been kicking around ideas about manual vs. region
vs. gc management. Can’t say I have a good link to it tho. http://www.coyotos.org/pipermail/bitc-dev/
Seems to me, tho I’m not well versed, like region stuff is a little
pie-in-the-sky still???
The BitC folks have been kicking around ideas about manual vs. region vs.
gc management. Can’t say I have a good link to it tho. http://www.coyotos.org/pipermail/bitc-dev/
Seems to me, tho I’m not well versed, like region stuff is a little
pie-in-the-sky still???
Even if one can use ML without using GC, it is still not easy to justify why
one wants to do it. I would like to see a compelling case for it.On Thursday, March 13, 2014 10:21:27 PM UTC-4, H Zhang wrote:
MLKit seems to have made good progress on this. But if your target is for
people who want to program in ML and run a ML top level this may not be
worth all the effort. But if you want to use ML to write a library or
extension where GC is undesirable this could make a big difference.
Thanks for the BitC reference. I will check it out.
Haitao
On Thursday, March 13, 2014 4:28:13 PM UTC-7, Raoul Duke wrote:
The BitC folks have been kicking around ideas about manual vs. region vs.
gc management. Can’t say I have a good link to it tho. http://www.coyotos.org/pipermail/bitc-dev/
Seems to me, tho I’m not well versed, like region stuff is a little
pie-in-the-sky still???