Menu
▾
▴
mlton-devel — [MLton] Developer community discussion
You can subscribe to this list here.
| 1970 |
Jan
(4592) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1999 |
Jan
|
Feb
(30) |
Mar
(43) |
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(176) |
May
(64) |
Jun
(32) |
Jul
(139) |
Aug
(145) |
Sep
(226) |
Oct
(137) |
Nov
(234) |
Dec
(71) |
| 2003 |
Jan
(163) |
Feb
(120) |
Mar
(47) |
Apr
(89) |
May
(191) |
Jun
(141) |
Jul
(160) |
Aug
(78) |
Sep
(59) |
Oct
(140) |
Nov
(133) |
Dec
(121) |
| 2004 |
Jan
(191) |
Feb
(102) |
Mar
(131) |
Apr
(70) |
May
(77) |
Jun
(100) |
Jul
(183) |
Aug
(166) |
Sep
(263) |
Oct
(81) |
Nov
(142) |
Dec
(235) |
| 2005 |
Jan
(160) |
Feb
(75) |
Mar
(71) |
Apr
(120) |
May
(106) |
Jun
(96) |
Jul
(388) |
Aug
(308) |
Sep
(155) |
Oct
(81) |
Nov
(237) |
Dec
(34) |
| 2006 |
Jan
(5) |
Feb
(47) |
Mar
(88) |
Apr
(96) |
May
(190) |
Jun
(100) |
Jul
(42) |
Aug
(48) |
Sep
(60) |
Oct
(168) |
Nov
(110) |
Dec
(95) |
| 2007 |
Jan
(32) |
Feb
(145) |
Mar
(67) |
Apr
(39) |
May
(28) |
Jun
(93) |
Jul
(48) |
Aug
(34) |
Sep
(30) |
Oct
(30) |
Nov
(53) |
Dec
(43) |
| 2008 |
Jan
(36) |
Feb
(41) |
Mar
(23) |
Apr
(29) |
May
(9) |
Jun
(12) |
Jul
(20) |
Aug
(43) |
Sep
(51) |
Oct
(49) |
Nov
(56) |
Dec
(6) |
| 2009 |
Jan
(8) |
Feb
(4) |
Mar
(3) |
Apr
(29) |
May
|
Jun
(42) |
Jul
(53) |
Aug
(9) |
Sep
(20) |
Oct
(50) |
Nov
(26) |
Dec
(37) |
| 2010 |
Jan
(5) |
Feb
(6) |
Mar
(11) |
Apr
(4) |
May
(25) |
Jun
(10) |
Jul
(3) |
Aug
(3) |
Sep
(8) |
Oct
(9) |
Nov
(6) |
Dec
(3) |
| 2011 |
Jan
(6) |
Feb
(22) |
Mar
(12) |
Apr
(11) |
May
(5) |
Jun
(18) |
Jul
(4) |
Aug
(4) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(6) |
Feb
(13) |
Mar
(5) |
Apr
(11) |
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
(1) |
Oct
(8) |
Nov
(2) |
Dec
(2) |
| 2013 |
Jan
|
Feb
(6) |
Mar
(7) |
Apr
(23) |
May
(32) |
Jun
(4) |
Jul
(7) |
Aug
(7) |
Sep
(1) |
Oct
(8) |
Nov
(6) |
Dec
(2) |
| 2014 |
Jan
(1) |
Feb
(11) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(5) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(15) |
| 2015 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(6) |
Aug
|
Sep
(2) |
Oct
(9) |
Nov
(6) |
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(12) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2018 |
Jan
|
Feb
(15) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(3) |
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
(1) |
| 2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(2) |
Dec
(4) |
| 2021 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
(1) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(15) |
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Matthew F. <mat...@gm...> - 2025-07-20 13:05:40
|
The amount of work to support MLB files really depends on the infrastructure around saving and restoring static environments and however the host compiler represents the program post-type checking. In MLton, elaboration of MLBs is at: https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate-mlbs.fun It's only 270 lines, but a lot of the interesting aspects come from the implementation of environments: https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate-env.sig MLton's implementation of environments is rather involved (and with a bit more mutable state than might be desired); I suspect that supporting MLBs would be simpler with a purely functional representation of environments. On Sat, Jul 19, 2025 at 10:54 AM Gergely Buday via MLton-devel < mlt...@li...> wrote: > Hi there, > > I ask this on the devel list as this is about the compiler itself. > > I would like to ask you to estimate how much work it would be to port > MLton's .mlb file support to Poly/ML. I have a student who is willing > to do it. > > I have found the semantics of ML Basis files: > > http://mlton.org/MLBasisSyntaxAndSemantics > > especially > > http://mlton.org/MLBasis.attachments/mlb-formal.pdf > > I have found the lexer and grammar files for it, which can be directly > used: > > https://github.com/MLton/mlton/tree/master/mlton/front-end > > Where is the part which actually "evaluates" an .mlb file? > > And, what do you think, how much work would it be to port it? > > The ML Kit also supports ML Basis files, they write their libraries > with .mlb files. So it would be useful to have this for Poly/ML as > well. > > Yours > > - Gergely > > > _______________________________________________ > MLton-devel mailing list > MLt...@li...; mlt...@ml... > https://lists.sourceforge.net/lists/listinfo/mlton-devel > |
|
From: Gergely B. <g....@sh...> - 2025-07-19 14:54:43
|
Hi there, I ask this on the devel list as this is about the compiler itself. I would like to ask you to estimate how much work it would be to port MLton's .mlb file support to Poly/ML. I have a student who is willing to do it. I have found the semantics of ML Basis files: http://mlton.org/MLBasisSyntaxAndSemantics especially http://mlton.org/MLBasis.attachments/mlb-formal.pdf I have found the lexer and grammar files for it, which can be directly used: https://github.com/MLton/mlton/tree/master/mlton/front-end Where is the part which actually "evaluates" an .mlb file? And, what do you think, how much work would it be to port it? The ML Kit also supports ML Basis files, they write their libraries with .mlb files. So it would be useful to have this for Poly/ML as well. Yours - Gergely |
|
From: Matthew F. <mat...@gm...> - 2025-04-24 18:54:46
|
Agreed, but will need help from an interested Debian developer. On Wed, Apr 23, 2025 at 12:40 PM Henry Cejtin <hen...@gm...> wrote: > I wish someone could do something to actually get a MLton package back > on Debian. > I am happy to help if I can do anything, although not sure what I can do. > It takes someone who is a Debian developer. > > I certainly mainly run Debian, and it wasn't any problem getting a > version to run, or making > it on the system. I don't know enough to know how to make a Debian > package. > If even just that part could be done, and put in the Mlton release > page, it would make it easier > for other people who run Debian or derivatives of it (like Ubuntu). > > > _______________________________________________ > MLton-devel mailing list > MLt...@li...; mlt...@ml... > https://lists.sourceforge.net/lists/listinfo/mlton-devel > |
|
From: Henry C. <hen...@gm...> - 2025-04-23 16:39:27
|
I wish someone could do something to actually get a MLton package back on Debian. I am happy to help if I can do anything, although not sure what I can do. It takes someone who is a Debian developer. I certainly mainly run Debian, and it wasn't any problem getting a version to run, or making it on the system. I don't know enough to know how to make a Debian package. If even just that part could be done, and put in the Mlton release page, it would make it easier for other people who run Debian or derivatives of it (like Ubuntu). |
|
From: Matthew F. <mat...@gm...> - 2025-04-19 09:47:20
|
We typically cite: Stephen Weeks. 2006. Whole-program compilation in MLton. In ML ’06: Proceedings of the 2006 workshop on ML (Portland, Oregon, USA). ACM, 1–1. and MLton n.d.. MLton web site. http://www.mlton.org. On Sat, Apr 19, 2025 at 5:36 AM 'Sasha Lopoukhine' via MLton-devel < mlt...@ml...> wrote: > Hi all, > > What's the best way to cite MLTon in a compiler paper? > > Best, > > Sasha > > > _______________________________________________ > MLton-devel mailing list > MLt...@li...; mlt...@ml... > https://lists.sourceforge.net/lists/listinfo/mlton-devel > |
|
From: 'Sasha L. v. MLton-d. <mlt...@ml...> - 2025-04-18 09:35:30
|
Hi all, What's the best way to cite MLTon in a compiler paper? Best, Sasha |
|
From: Adrian C. <ach...@ja...> - 2023-06-27 18:43:18
|
No worries and thank you both Matthew and Stephen for looking into this. Going forward, we will use https://mlton.sourceforge.io/ instead. Have a great week! On Tue, Jun 27, 2023 at 12:04 PM Matthew Fluet <mat...@gm...> wrote: > The CNAME doesn't seem to matter (both http://mlton.org and > http://www.mlton.org serve as expected), so I suggest just leaving it as > it is now. Maybe one day sourceforge will enable https for the registered > vhosts. > > > On Tue, Jun 27, 2023 at 11:22 AM Stephen Weeks <sw...@sw...> wrote: > >> Should I switch the CNAME back? >> >> On Tue, Jun 27, 2023 at 10:50 AM Matthew Fluet <mat...@gm...> >> wrote: >> >>> Unfortunately, MLton doesn't qualify for SourceForge's VHOST HTTPS >>> support (see https://sourceforge.net/p/forge/site-support/24738/). >>> You can always use mlton.sourceforge.io, which is HTTPS enabled. >>> >>> >>> On Mon, Jun 26, 2023 at 4:40 PM Stephen Weeks <sw...@sw...> wrote: >>> >>>> I updated the CNAME. >>>> >>>> On Mon, Jun 26, 2023 at 4:09 PM Matthew Fluet <mat...@gm...> >>>> wrote: >>>> >>>>> For a long time, SourceForge did not support VHOST to their HTTPS >>>>> hosting. But, that seems to have changed since the last time I checked: >>>>> https://sourceforge.net/p/forge/documentation/Custom%20VHOSTs/ >>>>> >>>>> Currently, the DNS is configured as: www.mlton.org CNAME to >>>>> vhost.sourceforge.net >>>>> but it would need to be configured as: www.mlton.org CNAME to >>>>> vhost2.sourceforge.net >>>>> >>>>> AFAIK, Stephen Weeks is still the one maintaining the mlton.org DNS >>>>> records. >>>>> >>>>> -Matthew >>>>> >>>>> On Mon, Jun 26, 2023 at 2:28 PM Adrian Cholewinski < >>>>> ach...@ja...> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Hope you are doing well! I wanted to reach out as I was told that >>>>>> this would be the best email to contact regarding this. We saw that >>>>>> http://www.mlton.org/ was not HTTPS enabled and was wondering if it >>>>>> would be possible to have that website be enabled for HTTPS? We have >>>>>> implemented a few things where if it is not HTTPS enabled then the website >>>>>> wouldn't be opened. There have been times where someone would like to >>>>>> browse the website but only ended up not being able to check it out. Let me >>>>>> know if this could be possible and hope you have an excellent Monday and >>>>>> week! >>>>>> >>>>>> Thank you, >>>>>> Adrian >>>>>> -- >>>>>> Adrian Cholewinski >>>>>> Jane Street Group | Information Technology >>>>>> 250 Vesey Street | New York, NY 10281 >>>>>> Tel: 646.759.6843 >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "MLton" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to mlt...@ml.... >>>>>> _______________________________________________ >>>>>> MLton-devel mailing list >>>>>> MLt...@li...; mlt...@ml... >>>>>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>>>>> >>>>> _______________________________________________ >>>>> MLton-devel mailing list >>>>> MLt...@li...; mlt...@ml... >>>>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>>>> >>>> _______________________________________________ >>>> MLton-devel mailing list >>>> MLt...@li...; mlt...@ml... >>>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>>> >>> _______________________________________________ >>> MLton-devel mailing list >>> MLt...@li...; mlt...@ml... >>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>> >> _______________________________________________ >> MLton-devel mailing list >> MLt...@li...; mlt...@ml... >> https://lists.sourceforge.net/lists/listinfo/mlton-devel >> > -- Adrian Cholewinski Jane Street Group | Information Technology 250 Vesey Street | New York, NY 10281 Tel: 646.759.6843 -- You received this message because you are subscribed to the Google Groups "MLton" group. To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml.... |
|
From: Matthew F. <mat...@gm...> - 2023-06-27 16:04:45
|
The CNAME doesn't seem to matter (both http://mlton.org and http://www.mlton.org serve as expected), so I suggest just leaving it as it is now. Maybe one day sourceforge will enable https for the registered vhosts. On Tue, Jun 27, 2023 at 11:22 AM Stephen Weeks <sw...@sw...> wrote: > Should I switch the CNAME back? > > On Tue, Jun 27, 2023 at 10:50 AM Matthew Fluet <mat...@gm...> > wrote: > >> Unfortunately, MLton doesn't qualify for SourceForge's VHOST HTTPS >> support (see https://sourceforge.net/p/forge/site-support/24738/). >> You can always use mlton.sourceforge.io, which is HTTPS enabled. >> >> >> On Mon, Jun 26, 2023 at 4:40 PM Stephen Weeks <sw...@sw...> wrote: >> >>> I updated the CNAME. >>> >>> On Mon, Jun 26, 2023 at 4:09 PM Matthew Fluet <mat...@gm...> >>> wrote: >>> >>>> For a long time, SourceForge did not support VHOST to their HTTPS >>>> hosting. But, that seems to have changed since the last time I checked: >>>> https://sourceforge.net/p/forge/documentation/Custom%20VHOSTs/ >>>> >>>> Currently, the DNS is configured as: www.mlton.org CNAME to >>>> vhost.sourceforge.net >>>> but it would need to be configured as: www.mlton.org CNAME to >>>> vhost2.sourceforge.net >>>> >>>> AFAIK, Stephen Weeks is still the one maintaining the mlton.org DNS >>>> records. >>>> >>>> -Matthew >>>> >>>> On Mon, Jun 26, 2023 at 2:28 PM Adrian Cholewinski < >>>> ach...@ja...> wrote: >>>> >>>>> Hello, >>>>> >>>>> Hope you are doing well! I wanted to reach out as I was told that this >>>>> would be the best email to contact regarding this. We saw that >>>>> http://www.mlton.org/ was not HTTPS enabled and was wondering if it >>>>> would be possible to have that website be enabled for HTTPS? We have >>>>> implemented a few things where if it is not HTTPS enabled then the website >>>>> wouldn't be opened. There have been times where someone would like to >>>>> browse the website but only ended up not being able to check it out. Let me >>>>> know if this could be possible and hope you have an excellent Monday and >>>>> week! >>>>> >>>>> Thank you, >>>>> Adrian >>>>> -- >>>>> Adrian Cholewinski >>>>> Jane Street Group | Information Technology >>>>> 250 Vesey Street | New York, NY 10281 >>>>> Tel: 646.759.6843 >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "MLton" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to mlt...@ml.... >>>>> _______________________________________________ >>>>> MLton-devel mailing list >>>>> MLt...@li...; mlt...@ml... >>>>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>>>> >>>> _______________________________________________ >>>> MLton-devel mailing list >>>> MLt...@li...; mlt...@ml... >>>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>>> >>> _______________________________________________ >>> MLton-devel mailing list >>> MLt...@li...; mlt...@ml... >>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>> >> _______________________________________________ >> MLton-devel mailing list >> MLt...@li...; mlt...@ml... >> https://lists.sourceforge.net/lists/listinfo/mlton-devel >> > _______________________________________________ > MLton-devel mailing list > MLt...@li...; mlt...@ml... > https://lists.sourceforge.net/lists/listinfo/mlton-devel > -- You received this message because you are subscribed to the Google Groups "MLton" group. To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml.... |
|
From: Stephen W. <sw...@sw...> - 2023-06-27 15:22:01
|
Should I switch the CNAME back? On Tue, Jun 27, 2023 at 10:50 AM Matthew Fluet <mat...@gm...> wrote: > Unfortunately, MLton doesn't qualify for SourceForge's VHOST HTTPS support > (see https://sourceforge.net/p/forge/site-support/24738/). > You can always use mlton.sourceforge.io, which is HTTPS enabled. > > > On Mon, Jun 26, 2023 at 4:40 PM Stephen Weeks <sw...@sw...> wrote: > >> I updated the CNAME. >> >> On Mon, Jun 26, 2023 at 4:09 PM Matthew Fluet <mat...@gm...> >> wrote: >> >>> For a long time, SourceForge did not support VHOST to their HTTPS >>> hosting. But, that seems to have changed since the last time I checked: >>> https://sourceforge.net/p/forge/documentation/Custom%20VHOSTs/ >>> >>> Currently, the DNS is configured as: www.mlton.org CNAME to >>> vhost.sourceforge.net >>> but it would need to be configured as: www.mlton.org CNAME to >>> vhost2.sourceforge.net >>> >>> AFAIK, Stephen Weeks is still the one maintaining the mlton.org DNS >>> records. >>> >>> -Matthew >>> >>> On Mon, Jun 26, 2023 at 2:28 PM Adrian Cholewinski < >>> ach...@ja...> wrote: >>> >>>> Hello, >>>> >>>> Hope you are doing well! I wanted to reach out as I was told that this >>>> would be the best email to contact regarding this. We saw that >>>> http://www.mlton.org/ was not HTTPS enabled and was wondering if it >>>> would be possible to have that website be enabled for HTTPS? We have >>>> implemented a few things where if it is not HTTPS enabled then the website >>>> wouldn't be opened. There have been times where someone would like to >>>> browse the website but only ended up not being able to check it out. Let me >>>> know if this could be possible and hope you have an excellent Monday and >>>> week! >>>> >>>> Thank you, >>>> Adrian >>>> -- >>>> Adrian Cholewinski >>>> Jane Street Group | Information Technology >>>> 250 Vesey Street | New York, NY 10281 >>>> Tel: 646.759.6843 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "MLton" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to mlt...@ml.... >>>> _______________________________________________ >>>> MLton-devel mailing list >>>> MLt...@li...; mlt...@ml... >>>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>>> >>> _______________________________________________ >>> MLton-devel mailing list >>> MLt...@li...; mlt...@ml... >>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>> >> _______________________________________________ >> MLton-devel mailing list >> MLt...@li...; mlt...@ml... >> https://lists.sourceforge.net/lists/listinfo/mlton-devel >> > _______________________________________________ > MLton-devel mailing list > MLt...@li...; mlt...@ml... > https://lists.sourceforge.net/lists/listinfo/mlton-devel > |
|
From: Matthew F. <mat...@gm...> - 2023-06-27 14:50:11
|
Unfortunately, MLton doesn't qualify for SourceForge's VHOST HTTPS support (see https://sourceforge.net/p/forge/site-support/24738/). You can always use mlton.sourceforge.io, which is HTTPS enabled. On Mon, Jun 26, 2023 at 4:40 PM Stephen Weeks <sw...@sw...> wrote: > I updated the CNAME. > > On Mon, Jun 26, 2023 at 4:09 PM Matthew Fluet <mat...@gm...> > wrote: > >> For a long time, SourceForge did not support VHOST to their HTTPS >> hosting. But, that seems to have changed since the last time I checked: >> https://sourceforge.net/p/forge/documentation/Custom%20VHOSTs/ >> >> Currently, the DNS is configured as: www.mlton.org CNAME to >> vhost.sourceforge.net >> but it would need to be configured as: www.mlton.org CNAME to >> vhost2.sourceforge.net >> >> AFAIK, Stephen Weeks is still the one maintaining the mlton.org DNS >> records. >> >> -Matthew >> >> On Mon, Jun 26, 2023 at 2:28 PM Adrian Cholewinski < >> ach...@ja...> wrote: >> >>> Hello, >>> >>> Hope you are doing well! I wanted to reach out as I was told that this >>> would be the best email to contact regarding this. We saw that >>> http://www.mlton.org/ was not HTTPS enabled and was wondering if it >>> would be possible to have that website be enabled for HTTPS? We have >>> implemented a few things where if it is not HTTPS enabled then the website >>> wouldn't be opened. There have been times where someone would like to >>> browse the website but only ended up not being able to check it out. Let me >>> know if this could be possible and hope you have an excellent Monday and >>> week! >>> >>> Thank you, >>> Adrian >>> -- >>> Adrian Cholewinski >>> Jane Street Group | Information Technology >>> 250 Vesey Street | New York, NY 10281 >>> Tel: 646.759.6843 >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "MLton" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to mlt...@ml.... >>> _______________________________________________ >>> MLton-devel mailing list >>> MLt...@li...; mlt...@ml... >>> https://lists.sourceforge.net/lists/listinfo/mlton-devel >>> >> _______________________________________________ >> MLton-devel mailing list >> MLt...@li...; mlt...@ml... >> https://lists.sourceforge.net/lists/listinfo/mlton-devel >> > _______________________________________________ > MLton-devel mailing list > MLt...@li...; mlt...@ml... > https://lists.sourceforge.net/lists/listinfo/mlton-devel > |
|
From: Stephen W. <sw...@sw...> - 2023-06-26 20:40:08
|
I updated the CNAME. On Mon, Jun 26, 2023 at 4:09 PM Matthew Fluet <mat...@gm...> wrote: > For a long time, SourceForge did not support VHOST to their HTTPS > hosting. But, that seems to have changed since the last time I checked: > https://sourceforge.net/p/forge/documentation/Custom%20VHOSTs/ > > Currently, the DNS is configured as: www.mlton.org CNAME to > vhost.sourceforge.net > but it would need to be configured as: www.mlton.org CNAME to > vhost2.sourceforge.net > > AFAIK, Stephen Weeks is still the one maintaining the mlton.org DNS > records. > > -Matthew > > On Mon, Jun 26, 2023 at 2:28 PM Adrian Cholewinski < > ach...@ja...> wrote: > >> Hello, >> >> Hope you are doing well! I wanted to reach out as I was told that this >> would be the best email to contact regarding this. We saw that >> http://www.mlton.org/ was not HTTPS enabled and was wondering if it >> would be possible to have that website be enabled for HTTPS? We have >> implemented a few things where if it is not HTTPS enabled then the website >> wouldn't be opened. There have been times where someone would like to >> browse the website but only ended up not being able to check it out. Let me >> know if this could be possible and hope you have an excellent Monday and >> week! >> >> Thank you, >> Adrian >> -- >> Adrian Cholewinski >> Jane Street Group | Information Technology >> 250 Vesey Street | New York, NY 10281 >> Tel: 646.759.6843 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "MLton" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mlt...@ml.... >> _______________________________________________ >> MLton-devel mailing list >> MLt...@li...; mlt...@ml... >> https://lists.sourceforge.net/lists/listinfo/mlton-devel >> > _______________________________________________ > MLton-devel mailing list > MLt...@li...; mlt...@ml... > https://lists.sourceforge.net/lists/listinfo/mlton-devel > |
|
From: Matthew F. <mat...@gm...> - 2023-06-26 20:09:06
|
For a long time, SourceForge did not support VHOST to their HTTPS hosting. But, that seems to have changed since the last time I checked: https://sourceforge.net/p/forge/documentation/Custom%20VHOSTs/ Currently, the DNS is configured as: www.mlton.org CNAME to vhost.sourceforge.net but it would need to be configured as: www.mlton.org CNAME to vhost2.sourceforge.net AFAIK, Stephen Weeks is still the one maintaining the mlton.org DNS records. -Matthew On Mon, Jun 26, 2023 at 2:28 PM Adrian Cholewinski < ach...@ja...> wrote: > Hello, > > Hope you are doing well! I wanted to reach out as I was told that this > would be the best email to contact regarding this. We saw that > http://www.mlton.org/ was not HTTPS enabled and was wondering if it would > be possible to have that website be enabled for HTTPS? We have > implemented a few things where if it is not HTTPS enabled then the website > wouldn't be opened. There have been times where someone would like to > browse the website but only ended up not being able to check it out. Let me > know if this could be possible and hope you have an excellent Monday and > week! > > Thank you, > Adrian > -- > Adrian Cholewinski > Jane Street Group | Information Technology > 250 Vesey Street | New York, NY 10281 > Tel: 646.759.6843 > > -- > You received this message because you are subscribed to the Google Groups > "MLton" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mlt...@ml.... > _______________________________________________ > MLton-devel mailing list > MLt...@li...; mlt...@ml... > https://lists.sourceforge.net/lists/listinfo/mlton-devel > |
|
From: Adrian C. <ach...@ja...> - 2023-06-26 14:50:23
|
Hello, Hope you are doing well! I wanted to reach out as I was told that this would be the best email to contact regarding this. We saw that http://www.mlton.org/ was not HTTPS enabled and was wondering if it would be possible to have that website be enabled for HTTPS? We have implemented a few things where if it is not HTTPS enabled then the website wouldn't be opened. There have been times where someone would like to browse the website but only ended up not being able to check it out. Let me know if this could be possible and hope you have an excellent Monday and week! Thank you, Adrian -- Adrian Cholewinski Jane Street Group | Information Technology 250 Vesey Street | New York, NY 10281 Tel: 646.759.6843 -- You received this message because you are subscribed to the Google Groups "MLton" group. To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml.... |
|
From: Matthew F. <mat...@gm...> - 2023-03-30 14:12:58
|
Higher-order, Typed, Inferred, Strict: ACM SIGPLAN ML Family Workshop September 8, 2023 (Friday) Seattle, WA, USA (day after main ICFP) Call for presentations: https://icfp23.sigplan.org/home/mlworkshop-2023 ML Family Workshop is an established informal workshop aiming to recognize the entire extended ML family and to provide the forum to present and discuss common issues: all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to promote the exchange of ideas and experience. The ML family workshop will be held in close coordination with the OCaml Users and Developers Workshop. We plan the workshop to an be in-person event with remote participation (streamed live). Speakers are generally expected to present in person (we will work to make remote presentations possible). We solicit proposals for contributed talks, in PDF format, with a short summary at the beginning and the indication of the submission category: Research Presentations, Experience Reports, Demos, and Informed Positions. The point of the submission should be clear from its first two pages (PC members are not obligated to read any further.) We particularly encourage talks about works in progress, presentations of negative results (things that were expected to but did not quite work out) and informed positions. * Deadline for talk proposals: ** Thursday June 1, 2023 ** * Notification of acceptance: ** Thursday July 6, 2023 ** * Workshop: ** Friday September 8, 2023 ** Program Committee Lars Bergstrom Google, USA Martin Elsman University of Copenhagen, Denmark Matthew Fluet Rochester Institute of Technology, USA Jacques Garrigue Nagoya University, Japan Oleg Kiselyov Tohoku University, Japan (Chair) Julia Lawall Inria-Paris, France Andrey Mokhov Jane Street, UK Benoît Montagu Inria-Rennes, France Guillaume Munch-Maccagnoni Inria, France Matija Pretnar University of Ljubljana, Slovenia Andreas Rossberg Germany Gabriel Scherer Inria-Saclay, France |
|
From: Matthew F. <mat...@gm...> - 2022-11-08 14:27:14
|
On Tue, Nov 8, 2022 at 5:34 AM Chris Cannam <ca...@al...> wrote: > > On Mon, 7 Nov 2022, at 19:28, Matthew Fluet wrote: > > So, you can see that with the default value of copy-generational-ratio > > 4.0, the runtime will never do generational collection. In the > > absence of generational collection, the card marking doesn't matter > > --- we're always doing a majorGC and tracing the whole heap. > > So when it is *not* intending to perform any minor GCs, does it partition the heap differently? e.g. half and half old-gen and nursery and then swap the two after a major GC? If the generational GC isn't requested via the copy-generational-ratio, then the nursery begins immediately after the old-gen and allocation will proceed to fill the entire heap. Then a major copying collection will copy live data into a new heap. When major copying collection is used, then the heaps that are allocated are either exactly half of fixed-heap or at most half of max-heap in order to ensure that there is enough space for a to-space heap equal in size to the from-space heap. In the absence of fixed-heap and max-heap, I don't recall exactly the policy. (I.e., whether the heap is resized to bytesLive * live-ratio or to 0.5 * bytesLive * live-ratio). > Under what conditions does a mark-compact collection occur? Is that only when running out of heap space? Both the generational and the mark-compact gc kick in when bytesLive approaches RAM. The basic heuristic is that a copying collection is more efficient than mark compact (copying is proportional to the size of the live data (which is hopefully a fraction of the whole heap, though quite possibly not if the live data is approaching RAM size), while mark-compact is proportional to the size of the entire heap (live and dead data)). > I see the reference to Sansom 1991 - I haven't managed to find a copy that isn't paywalled, but also it's perhaps for the best if I don't read around the subject *too* thoroughly or I might never get anything else done! Hmm, it does seem that our Sansom link to CiteSeer is broken, but the paper seems to be accessible at: https://citeseerx.ist.psu.edu/doc_view/pid/95b037dfc30a999d5a0326bc7a3eeeef21dfdc5a There are a lot of knobs that one can turn on a garbage collector. I would like to rework MLton's gc controls to be a bit more generic and allow them to be controlled from SML code as well. Something like `val MLton.GC.setFloatOption: string * real -> bool` and `val MLton.GC.getFloatOption: string -> real option`, where the bool/option would be used to indicate whether or not the string is recognized as a GC control. |
|
From: Chris C. <ca...@al...> - 2022-11-08 10:34:23
|
On Mon, 7 Nov 2022, at 19:28, Matthew Fluet wrote: > So, you can see that with the default value of copy-generational-ratio > 4.0, the runtime will never do generational collection. In the > absence of generational collection, the card marking doesn't matter > --- we're always doing a majorGC and tracing the whole heap. That's interesting, I hadn't noticed that the effect could be quite so... binary. Yet there it is in the gc-summary output: With default options GC type time ms number bytes bytes/sec ------------- ------- ------- --------------- --------------- copying 92 89 509,627,808 5,539,432,695 mark-compact 0 0 0 - minor 0 0 0 - With copy-generational-ratio 10.0 GC type time ms number bytes bytes/sec ------------- ------- ------- --------------- --------------- copying 6 9 20,408,272 3,401,378,666 mark-compact 0 0 0 - minor 72 586 93,072,328 1,292,671,222 It makes little difference overall in this case, both are in the 3-4% range for time spent in GC. So when it is *not* intending to perform any minor GCs, does it partition the heap differently? e.g. half and half old-gen and nursery and then swap the two after a major GC? Under what conditions does a mark-compact collection occur? Is that only when running out of heap space? I see the reference to Sansom 1991 - I haven't managed to find a copy that isn't paywalled, but also it's perhaps for the best if I don't read around the subject *too* thoroughly or I might never get anything else done! Chris |
|
From: Matthew F. <mat...@gm...> - 2022-11-07 19:29:21
|
On Mon, Nov 7, 2022 at 11:13 AM Chris Cannam
<ca...@al...> wrote:
> On Mon, 7 Nov 2022, at 15:44, Matthew Fluet wrote:
> > Untested, but something like:
> >
> > [...]
> > + if (numObjptrs > 0 and l > 0) {
> > + markCard (s, ad);
> > + }
> > +
> > eltSize = bytesNonObjptrs + (numObjptrs * OBJPTR_SIZE);
> > GC_memmove (as + eltSize * ss, ad + eltSize * ds, eltSize * l);
> > }
> >
> > should do the trick.
>
> It does! With that added, it runs successfully - and produces the same results with copy-generational-ratio 10.0 as it did with the default arguments.
Excellent!
> I wonder what a minimal test-case for this would look like. If this copy is part of an optimisation for constructing a sequence, does this mean it is constructing it directly into the old generation heap, rather than in the nursery? If so, why? Is there a rule that it will do that for sequences above a certain size? Is that affected by copy-generational-ratio?
It doesn't necessarily mean that the sequence was allocated directly
in the old generation. A sequence allocation and initialization is a
multi-step process: allocate an uninitialized sequence of the correct
size, then initialize the elements. If there is non-trivial
computation involved in creating the elements, then it is possible for
a GC to occur, which will copy the partially initialized sequence from
the nursery to the old gen, then initialization resumes with
allocating elements (in the nursery) and updating the sequence to
point to the elements. For instance, a Vector.tabulate has this kind
of behavior (though, it does not invoke GC_sequenceCopy).
There is a GC control that affects whether a large sequence is
directly allocated in the old generation:
https://github.com/MLton/mlton/blob/master/runtime/gc/sequence-allocate.c#L49
with the default value of 0x100000 bytes.
That said, I suspect that it is the case that the array which has the
intergenerational point was directly allocated in the old generation.
A brief look at the Basis Library implementation suggests that the
initialization loops that perform GC_sequenceCopy are all
non-allocating loops. Essentially, all of the data to be copied into
the destination sequence is gathered ahead of time (typically in order
to calculate the size of the to-be-allocated sequence), and then it is
a simple tail-recursive loop over a list of slices performing
GC_sequenceCopy.
The oldGenSequenceSize is not affected by copy-generational-ratio.
What is affected by copy-generational-ratio is whether or not minor
GCs are executed at all. Here is the code that sets the `canMinor`
flag:
https://github.com/MLton/mlton/blob/master/runtime/gc/gc_state.c#L71
The critical condition is:
(float)h->size / (float)s->lastMajorStatistics.bytesLive <=
s->controls.ratios.copyGenerational
The default value for copy-generational-ratio is 4.0. Note also that
the default value for live-ratio is 8.0. (See
https://github.com/MLton/mlton/blob/master/runtime/gc/init.c#L287.)
After each (major) garbage collection, MLton tries to resize the heap
so as to be live-ratio times the bytesLive. There is some "wiggle
room" in the resizing; i.e., don't resize if the current heap size is
"close enough" and try not resize beyond ramSlot (default 0.5) times
RAM. But, for "small programs" on machines with "big memory", the
heap will pretty often be 8.0 times the lastMajorStatistics.bytesLive.
So, you can see that with the default value of copy-generational-ratio
4.0, the runtime will never do generational collection. In the
absence of generational collection, the card marking doesn't matter
--- we're always doing a majorGC and tracing the whole heap. On the
other hand, with copy-generational-ratio 10.0, the runtime will always
do generational collection, so you are much more likely to trigger the
card marking bug.
-Matthew
|
|
From: Chris C. <ca...@al...> - 2022-11-07 16:13:20
|
On Mon, 7 Nov 2022, at 15:44, Matthew Fluet wrote:
> Untested, but something like:
>
> [...]
> + if (numObjptrs > 0 and l > 0) {
> + markCard (s, ad);
> + }
> +
> eltSize = bytesNonObjptrs + (numObjptrs * OBJPTR_SIZE);
> GC_memmove (as + eltSize * ss, ad + eltSize * ds, eltSize * l);
> }
>
> should do the trick.
It does! With that added, it runs successfully - and produces the same results with copy-generational-ratio 10.0 as it did with the default arguments.
I wonder what a minimal test-case for this would look like. If this copy is part of an optimisation for constructing a sequence, does this mean it is constructing it directly into old generation heap, rather than in the nursery? If so, why? Is there a rule that it will do that for sequences above a certain size? Is that affected by copy-generational-ratio?
Chris
|
|
From: Matthew F. <mat...@gm...> - 2022-11-07 15:45:10
|
Ah, brilliant -- bug identified!! On Mon, Nov 7, 2022 at 8:54 AM Chris Cannam <ca...@al...> wrote: > But I guess what we actually need to know (?) is what causes the pointer in old generation to be written, pointing to this nursery address. So I added a second watchpoint, and the order of events is like this: > > 1. Nursery address (346e00) is initialised to 1 in sequence allocate > 2. Nursery address (346e00) and its surroundings are modified in sequence update > 3. Old-generation address (27308) is set to point to the nursery address > > And (3) occurs not from a sequence update, but within a call to GC_sequenceCopy: > ... > > In the call to GC_sequenceCopy, the destination address is in the old generation and the source address is in the nursery. But it appears to be called from generated code, not from a GC action - there is no GC occurring at the time. Why is something outside a GC copying directly to the old generation? Am I entirely misunderstanding? > > (The program doesn't call any primitives or MLton functions itself, it doesn't use copyArray/copyVector) No misunderstanding on your part at all. A lot of the runtime functions are "misnamed", in the sense that we use "GC_" for a lot of runtime functions that need to know about the GC (e.g., object layout, heap invariants), even if they are not strictly speaking performed during a garbage collection. As you have discovered, there is another way besides `Array.update` and reference `:=` for an old gen object to be updated with a pointer to a nursery object. The `GC_sequenceCopy` was added 5 years ago to improve the performance of a number of array and vector construction functions. As noted in the backtrace, using `memmove` and its platform-dependent multi-word vector instructions is a big improvement over MLton's old element-by-element copying loop. See https://github.com/MLton/mlton/blob/master/CHANGELOG.adoc?plain=1#L592 for some details. Even if your code does not directly call `Array.copy` or `Array.copyVec`, there are a lot of array and vector construction functions in the MLton implementation of the Standard Basis Library that do use `GC_sequenceCopy`. But, the `GC_sequenceCopy` function (https://github.com/MLton/mlton/blob/master/runtime/gc/sequence.c#L73) fails to mark the card of the array object that is being updated. The places where `GC_sequenceCopy` was getting us the biggest wins was in string creation operations, where the elements are characters and not object pointers (so, no need for card marking). But, of course, the operation makes sense for arrays with elements containing pointer fields, so it should mark cards. And, as noted, these are usually used in array and vector initialization functions, so typically the new array/vector is in the nursery and the initializing elements are previously allocated (in the old gen or nursery), so no intergenerational pointers are created. That probably mostly explains why it was able to go so long without being noticed. Untested, but something like: ❯ git diff diff --git a/runtime/gc/sequence.c b/runtime/gc/sequence.c index 6e2035555..4517e71dc 100644 --- a/runtime/gc/sequence.c +++ b/runtime/gc/sequence.c @@ -85,6 +85,10 @@ void GC_sequenceCopy (GC_state s, pointer ad, size_t ds, pointer as, size_t ss, splitHeader(s, header, &tag, NULL, &bytesNonObjptrs, &numObjptrs); assert (tag == SEQUENCE_TAG); + if (numObjptrs > 0 and l > 0) { + markCard (s, ad); + } + eltSize = bytesNonObjptrs + (numObjptrs * OBJPTR_SIZE); GC_memmove (as + eltSize * ss, ad + eltSize * ds, eltSize * l); } should do the trick. Excellent work and debugging skills! -Matthew |
|
From: Chris C. <ca...@al...> - 2022-11-07 13:54:15
|
On Sun, 6 Nov 2022, at 20:49, Matthew Fluet wrote:
> Just before this, there must be a
> T(Q, n) = CPointer_add (Frontier, (Word64)(0x8ull));
> T(P, 1) = (Objptr)T(Q, n);
Yes, there was. Thank you - this is all really informative, but I think I actually made a mistake in what I was tracking with the debugger. I realise I had been setting a watchpoint on the address *within the nursery* to tell me when that was modified - not on the address in the old generation that points to the nursery address.
So the code I quoted above - that is setting elements within a sequence of records in nursery allocation. The cards it marks all appear to be for addresses within the nursery, at or around the address that later fails the invariant check (because it has been overlooked in copy collection).
But I guess what we actually need to know (?) is what causes the pointer in old generation to be written, pointing to this nursery address. So I added a second watchpoint, and the order of events is like this:
1. Nursery address (346e00) is initialised to 1 in sequence allocate
2. Nursery address (346e00) and its surroundings are modified in sequence update
3. Old-generation address (27308) is set to point to the nursery address
And (3) occurs not from a sequence update, but within a call to GC_sequenceCopy:
Hardware watchpoint 1: *0x0000080000027308
Old value = 1433506504
New value = 3436032
__memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:418
418 VMOVU %VEC(5), -(VEC_SIZE * 2)(%rdi, %rdx)
(gdb) where
#0 __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:418
#1 0x00005555556d0a5e in GC_memmove (src=0x80000348e80 "(\201\a", dst=0x80000027260 "(\201\a",
size=176) at gc/virtual-memory.c:41
#2 0x00005555556e1fbd in GC_sequenceCopy (s=0x555555719700 <gcState.0>, ad=0x80000027260 "(\201\a",
ds=0, as=0x80000348e80 "(\201\a", ss=0, l=22) at gc/sequence.c:89
#3 0x00005555555c9287 in Chunk_1 (GCState=0x555555719700 <gcState.0>, StackTop=0x80000000238,
Frontier=0x80000348f30, nextBlock=306) at program.0.c:3698
#4 0x00005555555695d0 in MLton_trampoline (s=0x555555719700 <gcState.0>, nextBlock=292,
mayReturnToC=false) at /usr/local/lib/mlton/include/c-main.h:35
#5 0x0000555555569858 in MLton_main (argc=4, argv=0x7fffffffe3c8) at program.2.c:5216
#6 0x000055555556987f in main (argc=4, argv=0x7fffffffe3c8) at program.2.c:5217
In the call to GC_sequenceCopy, the destination address is in the old generation and the source address is in the nursery. But it appears to be called from generated code, not from a GC action - there is no GC occurring at the time. Why is something outside a GC copying directly to the old generation? Am I entirely misunderstanding?
(The program doesn't call any primitives or MLton functions itself, it doesn't use copyArray/copyVector)
There is no sign of any card marking around the call to GC_sequenceCopy:
L_8647:
/* TW32(0): Word32 = WordS64_lt (TW64(1): Word64, 0x5:w64) */
T(W32, 0) = WordS64_lt (T(W64, 1), (Word64)(0x5ull));
/* switch {test = TW32(0): Word32, default = None, expect = None, cases = ((0x0:w32, L_8646), (0x1:w32, L_8644))} */
if (T(W32, 0)) goto L_8644; else goto L_8646;
L_8646:
/* CCall {args = (<GCState>, TP(6): Objptr (opt_98), TW64(2): Word64, Cast (TP(0): Objptr (opt_98), Objptr (opt_13)), 0x0:w64, TW64(1): Word64), func = {args = (CPointer, Objptr (opt_98), Word64, Objptr (opt_13), Word64, Word64), convention = cdecl, inline = false, kind = Runtime {bytesNeeded = None, ensuresBytesFree = None, mayGC = false, maySwitchThreadsFrom = false, maySwitchThreadsTo = false, modifiesFrontier = false, readsStackTop = false, writesStackTop = false}, prototype = {args = (CPointer, Objptr, Word64, Objptr, Word64, Word64), res = None}, return = Bits0, symbolScope = private, target = GC_sequenceCopy}, return = Some {return = L_8645, size = None}} */
GC_sequenceCopy (GCState, T(P, 6), T(W64, 2), (Objptr)T(P, 0), (Word64)(0x0ull), T(W64, 1));
goto L_8645;
L_8645:
/* TW64(0): Word64 = SW64(48): Word64 */
T(W64, 0) = S(Word64, 48);
/* SP(32): Objptr (opt_94) = TP(5): Objptr (opt_94) */
S(Objptr, 32) = T(P, 5);
/* Goto loop_262 */
goto loop_262;
Chris
|
|
From: Matthew F. <mat...@gm...> - 2022-11-06 20:49:58
|
On Sun, Nov 6, 2022 at 2:04 PM Chris Cannam <ca...@al...> wrote: > > On Sun, 6 Nov 2022, at 15:52, Matthew Fluet wrote: > > If the address of the bad intergenerational pointer is consistent > > between runs > > It is. > > > set a hardware watchpoint on the address > > that will be written with the pointer into the nursery and then look at > > the C/assembly that immediately follows the write; that should mark a > > corresponding card. > > According to gdb, and using the C-codegen output, the last two writes to > that address before the failing GC are: > > * initialisation to 1 from GC_sequenceAllocate:87, then > Makes sense. GC_sequenceAllocate is allocating an array and needs to initialize all pointer fields with a pointer-sized non-pointer (1); this is so that a GC that occurs before the actual initialization of the array elements won't see uninitialized pointers and try to follow them. > * updating to another value (3436048) in line 33191 of this code: > > Just before this, there must be a T(Q, n) = CPointer_add (Frontier, (Word64)(0x8ull)); T(P, 1) = (Objptr)T(Q, n); > 33184 Frontier = CPointer_add (Frontier, (Word64)(0x28ull)); > 33185 O(Word64, T(P, 1), 0) = S(Word64, 128); > 33186 O(Real64, T(P, 1), 8) = S(Real64, 136); > 33187 O(Real64, T(P, 1), 16) = S(Real64, 144); > 33188 O(Word32, T(P, 1), 24) = T(W32, 0); > This has allocated and initialized a new object. > 33189 T(W64, 0) = WordU64_rshift ((Word64)S(Objptr, 112), > (Word32)(0x8ull)); > 33190 X(Word8, O(CPointer, GCState, 936), T(W64, 0), 1, 0) = > (Word8)(0x1ull); > This is the card marking. GCState+936 corresponds to the base of the `cardMapAbsolute` field within the `struct GC_generationalMaps` within the `struct GC_state`. This looks correct. The `S(Objptr, 112)` is the stack variable holding the base address of the object about to be updated. The `rshift` performs the division by 256 and the `X(...)` computes the array element of the card map to be updated to 0x1ull (true). > 33191 X(Objptr, S(Objptr, 112), S(Word64, 88), 8, 0) = T(P, 1); > This is the actual write that creates the intergenerational pointer. > 33192 T(W64, 1) = Word64_add (S(Word64, 88), (Word64)(0x1ull)); > 33193 S(Word64, 88) = T(W64, 1); > 33194 goto loop_277; > 33195 > 33196 loop_277: > 33197 T(W32, 0) = WordS64_lt (S(Word64, 88), S(Word64, 104)); > 33198 if (T(W32, 0)) goto L_9521; else goto L_9522; > 33199 > 33200 L_9522: > 33201 O(Word64, S(Objptr, 112), -8) = (Word64)(0x1Dull); > 33202 T(W64, 0) = WordU64_rshift ((Word64)S(Objptr, 0), > (Word32)(0x8ull)); > 33203 X(Word8, O(CPointer, GCState, 936), T(W64, 0), 1, 0) = > (Word8)(0x1ull); > 33204 X(Objptr, S(Objptr, 0), S(Word64, 40), 8, 0) = > (Objptr)S(Objptr, 112); > This is another card mark and array update. > 33205 T(W64, 1) = Word64_add (S(Word64, 40), (Word64)(0x1ull)); > 33206 S(Word64, 40) = T(W64, 1); > 33207 goto loop_278; > > > Is it possible to get any more annotation in the C output, about which bit > of the source something in the output might correspond to? > Compiling with `-native-commented 2` will insert a bunch of comments in the generated C file with the corresponding Machine IR. It occurs to me that the comment in `assertIsObjptrInFromSpaceOrImmutableMutableOrRootStaticHeap` about false positives with stacks also applies to arrays. The card of the address of the beginning of the array is marked, but, if the array is larger than 256 bytes, then an intergenerational pointer can occur at an address that corresponds to a card after the card of the beginning of the array. I looked briefly at the code that walks the card map to find intergenerational roots ( https://github.com/MLton/mlton/blob/master/runtime/gc/forward.c#L191) and don't see anything obviously amiss. But, it must be something rather subtle, because this hasn't been a pervasive problem with the generational collector. -Matthew |
|
From: Chris C. <ca...@al...> - 2022-11-06 19:04:33
|
On Sun, 6 Nov 2022, at 15:52, Matthew Fluet wrote: > If the address of the bad intergenerational pointer is consistent > between runs It is. > set a hardware watchpoint on the address > that will be written with the pointer into the nursery and then look at > the C/assembly that immediately follows the write; that should mark a > corresponding card. According to gdb, and using the C-codegen output, the last two writes to that address before the failing GC are: * initialisation to 1 from GC_sequenceAllocate:87, then * updating to another value (3436048) in line 33191 of this code: 33184 Frontier = CPointer_add (Frontier, (Word64)(0x28ull)); 33185 O(Word64, T(P, 1), 0) = S(Word64, 128); 33186 O(Real64, T(P, 1), 8) = S(Real64, 136); 33187 O(Real64, T(P, 1), 16) = S(Real64, 144); 33188 O(Word32, T(P, 1), 24) = T(W32, 0); 33189 T(W64, 0) = WordU64_rshift ((Word64)S(Objptr, 112), (Word32)(0x8ull)); 33190 X(Word8, O(CPointer, GCState, 936), T(W64, 0), 1, 0) = (Word8)(0x1ull); 33191 X(Objptr, S(Objptr, 112), S(Word64, 88), 8, 0) = T(P, 1); 33192 T(W64, 1) = Word64_add (S(Word64, 88), (Word64)(0x1ull)); 33193 S(Word64, 88) = T(W64, 1); 33194 goto loop_277; 33195 33196 loop_277: 33197 T(W32, 0) = WordS64_lt (S(Word64, 88), S(Word64, 104)); 33198 if (T(W32, 0)) goto L_9521; else goto L_9522; 33199 33200 L_9522: 33201 O(Word64, S(Objptr, 112), -8) = (Word64)(0x1Dull); 33202 T(W64, 0) = WordU64_rshift ((Word64)S(Objptr, 0), (Word32)(0x8ull)); 33203 X(Word8, O(CPointer, GCState, 936), T(W64, 0), 1, 0) = (Word8)(0x1ull); 33204 X(Objptr, S(Objptr, 0), S(Word64, 40), 8, 0) = (Objptr)S(Objptr, 112); 33205 T(W64, 1) = Word64_add (S(Word64, 40), (Word64)(0x1ull)); 33206 S(Word64, 40) = T(W64, 1); 33207 goto loop_278; I checked at the watchpoint and (as in line 33191) StackTop+112 does indeed contain the nursery pointer address, so this looks like the right thing. Then the conditional branch at line 33198 is not taken, so execution goes on to L_9522 below it. Lines 33202-33204 look like it could possibly be card-marking? But this is making my head hurt a little, so I may have to come back to it. If I continue from that watchpoint, the next thing that happens is the failed invariant check. Is it possible to get any more annotation in the C output, about which bit of the source something in the output might correspond to? Chris |
|
From: Matthew F. <mat...@gm...> - 2022-11-06 15:52:27
|
Definitely looks like a problem with card marking. What's surprising is that that is a very simple operation; anytime there is a write of a object pointer into the field of an object (as induced by either `Array.update` or reference `:=`), we simply write TRUE into the card for the address of the written-to object divided by 256. See: https://github.com/MLton/mlton/blob/master/mlton/backend/ssa2-to-rssa.fun#L638 https://github.com/MLton/mlton/blob/master/mlton/backend/ssa2-to-rssa.fun#L945 If the address of the bad intergenerational pointer is consistent between runs, then I would run the program under gdb until the end of the last successful GC, then set a hardware watchpoint on the address that will be written with the pointer into the nursery and then look at the C/assembly that immediately follows the write; that should mark a corresponding card. On Sun, Nov 6, 2022 at 10:03 AM Chris Cannam <ca...@al...> wrote: > Thanks for the clear explanation! > > On Sun, 6 Nov 2022, at 02:43, Matthew Fluet wrote: > > We should be checking that intergenerational pointers have their > > corresponding card marked, but that test is currently disabled: > > https://github.com/MLton/mlton/blob/master/runtime/gc/invariant.c#L23 > > I'm guessing that if we enabled/fixed that, then we would trip the > > invariant at the beginning of the GC > > Indeed it does - I enabled that (but made it non-fatal because of the > warning about false positives) and it logs > > gc.c: intergenerational pointer from 0x0000080000027308 to > 0x0000080000346e00 with unmarked card. > > after the starting GC messages. It's not the only one in this GC either - > there are 9 of them - though again I see the caveat about false positives > in the comment. > > > Chris > > > _______________________________________________ > MLton-devel mailing list > MLt...@li...; mlt...@ml... > https://lists.sourceforge.net/lists/listinfo/mlton-devel > |
44 messages has been excluded from this view by a project administrator.
