* First-class continuations in Kawa @ 2018-01-20 0:49 Duncan Mak 2018-01-20 6:47 ` Per Bothner 0 siblings, 1 reply; 18+ messages in thread From: Duncan Mak @ 2018-01-20 0:49 UTC (permalink / raw) To: kawa mailing list Hello, I came across Andrea Bernardini's thesis called First-Class Continuations on the Java Virtual Machine: An Implementation within the Kawa Scheme Compiler just the other day. https://www.politesi.polimi.it/bitstream/10589/108685/3/2015_07_Bernardini.pdf What happened to that work, was it integrated into the mainline release of Kawa? Thanks! -- Duncan. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2018-01-20 0:49 First-class continuations in Kawa Duncan Mak @ 2018-01-20 6:47 ` Per Bothner 2018-01-20 16:07 ` Duncan Mak 0 siblings, 1 reply; 18+ messages in thread From: Per Bothner @ 2018-01-20 6:47 UTC (permalink / raw) To: Duncan Mak, kawa mailing list On 01/19/2018 04:48 PM, Duncan Mak wrote: > Hello, > > I came across Andrea Bernardini's thesis called First-Class > Continuations on the Java Virtual Machine: An Implementation within > the Kawa Scheme Compiler just the other day. > > https://www.politesi.polimi.it/bitstream/10589/108685/3/2015_07_Bernardini.pdf > > What happened to that work, was it integrated into the mainline release of Kawa? Sorry, no. Andrea's work is available in the 'callcc' branch, but it has not been merged into master. Worse, updates to master have not been merged into the callcc branch. It would be useful to at least update the callcc branch with recent changes, and then test, evaluate, and benchmark it. If it is useful, it should be merged in. Even if it is slow, as long as it doesn't hurt the default behavior. It is my fault that hasn't been done, but there were always other things to do. Long time ago, I started on another implementation of continuations based on switch statements. (Each continuation point would be associated with an index, and each function would start with a switch statement with jumps to the continuation points. Capturing a continuation would essentially be saving the corresponding switch index.) Some of that code is still in Kawa, but commented out. Following up on that idea might be more efficient. Which isn't really a good excuse for not merging in Andrea's work. If someone is interested in following up on this work, that would be great. -- --Per Bothner per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2018-01-20 6:47 ` Per Bothner @ 2018-01-20 16:07 ` Duncan Mak 2018-01-20 23:20 ` Andrea Bernardini 0 siblings, 1 reply; 18+ messages in thread From: Duncan Mak @ 2018-01-20 16:07 UTC (permalink / raw) To: Per Bothner; +Cc: kawa mailing list Looks interesting. Is the work contained in only these two commits? https://gitlab.com/kashell/Kawa/commit/a8e678ebf7216e9fad9238e0b1c2442ea371c63c https://gitlab.com/kashell/Kawa/commit/f4228b57936de5a84dba0afcfac54196bec86fa4 Duncan. On Sat, Jan 20, 2018 at 1:46 AM, Per Bothner <per@bothner.com> wrote: > On 01/19/2018 04:48 PM, Duncan Mak wrote: >> >> Hello, >> >> I came across Andrea Bernardini's thesis called First-Class >> Continuations on the Java Virtual Machine: An Implementation within >> the Kawa Scheme Compiler just the other day. >> >> >> https://www.politesi.polimi.it/bitstream/10589/108685/3/2015_07_Bernardini.pdf >> >> What happened to that work, was it integrated into the mainline release of >> Kawa? > > > Sorry, no. Andrea's work is available in the 'callcc' branch, but it has not > been merged into master. Worse, updates to master have not been merged > into the callcc branch. > > It would be useful to at least update the callcc branch with recent changes, > and then test, evaluate, and benchmark it. If it is useful, it should be > merged in. > Even if it is slow, as long as it doesn't hurt the default behavior. It is > my fault > that hasn't been done, but there were always other things to do. > > Long time ago, I started on another implementation of continuations based on > switch statements. (Each continuation point would be associated with an > index, > and each function would start with a switch statement with jumps to the > continuation points. Capturing a continuation would essentially be saving > the > corresponding switch index.) Some of that code is still in Kawa, but > commented out. Following up on that idea might be more efficient. Which > isn't really a good excuse for not merging in Andrea's work. > > If someone is interested in following up on this work, that would be great. > -- > --Per Bothner > per@bothner.com http://per.bothner.com/ -- Duncan. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2018-01-20 16:07 ` Duncan Mak @ 2018-01-20 23:20 ` Andrea Bernardini 2018-02-21 0:21 ` Andrea Bernardini 0 siblings, 1 reply; 18+ messages in thread From: Andrea Bernardini @ 2018-01-20 23:20 UTC (permalink / raw) To: Duncan Mak; +Cc: Per Bothner, kawa mailing list Yep, that's it. The whole work was originally submitted as patch. It is also my fault If this was never merged into master. I remember that I started working on a switch-based variant of my work after getting some high level suggestions from Per. That turned out to be a fair amount of work and I didn't have much time, so I didn't manage to put together anything working. I also have some working code that I mentioned in my thesis but didn't end up in that patch, as it wasn't well tested. This was mainly for delimited continuations and for the debugger. I'll share this soon in a GitLab fork so it doesn't get lost. Andrea On 20 January 2018 at 16:06, Duncan Mak <duncanmak@gmail.com> wrote: > Looks interesting. > > Is the work contained in only these two commits? > > https://gitlab.com/kashell/Kawa/commit/a8e678ebf7216e9fad9238e0b1c2442ea371c63c > https://gitlab.com/kashell/Kawa/commit/f4228b57936de5a84dba0afcfac54196bec86fa4 > > > Duncan. > > > On Sat, Jan 20, 2018 at 1:46 AM, Per Bothner <per@bothner.com> wrote: >> On 01/19/2018 04:48 PM, Duncan Mak wrote: >>> >>> Hello, >>> >>> I came across Andrea Bernardini's thesis called First-Class >>> Continuations on the Java Virtual Machine: An Implementation within >>> the Kawa Scheme Compiler just the other day. >>> >>> >>> https://www.politesi.polimi.it/bitstream/10589/108685/3/2015_07_Bernardini.pdf >>> >>> What happened to that work, was it integrated into the mainline release of >>> Kawa? >> >> >> Sorry, no. Andrea's work is available in the 'callcc' branch, but it has not >> been merged into master. Worse, updates to master have not been merged >> into the callcc branch. >> >> It would be useful to at least update the callcc branch with recent changes, >> and then test, evaluate, and benchmark it. If it is useful, it should be >> merged in. >> Even if it is slow, as long as it doesn't hurt the default behavior. It is >> my fault >> that hasn't been done, but there were always other things to do. >> >> Long time ago, I started on another implementation of continuations based on >> switch statements. (Each continuation point would be associated with an >> index, >> and each function would start with a switch statement with jumps to the >> continuation points. Capturing a continuation would essentially be saving >> the >> corresponding switch index.) Some of that code is still in Kawa, but >> commented out. Following up on that idea might be more efficient. Which >> isn't really a good excuse for not merging in Andrea's work. >> >> If someone is interested in following up on this work, that would be great. >> -- >> --Per Bothner >> per@bothner.com http://per.bothner.com/ > > > > -- > Duncan. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2018-01-20 23:20 ` Andrea Bernardini @ 2018-02-21 0:21 ` Andrea Bernardini 2018-02-22 0:38 ` Duncan Mak 0 siblings, 1 reply; 18+ messages in thread From: Andrea Bernardini @ 2018-02-21 0:21 UTC (permalink / raw) To: Duncan Mak; +Cc: Per Bothner, kawa mailing list Hi All, Regarding delimited continuations, you can see the needed changes here https://gitlab.com/andrebask/Kawa/compare/callcc...delimited-continuations Let me know if you are interested in this at all, shouldn't be difficult to add this once Duncan's pull request is merged in. In the same fork there's also a branch with the debugger implementation, however I'm not sure how useful that could be, it was quite experimental Thanks, Andrea On 20 January 2018 at 23:20, Andrea Bernardini <andrebask@gmail.com> wrote: > Yep, that's it. The whole work was originally submitted as patch. > > It is also my fault If this was never merged into master. I remember > that I started working on a switch-based variant of my work after > getting some high level suggestions from Per. That turned out to be a > fair amount of work and I didn't have much time, so I didn't manage to > put together anything working. > > I also have some working code that I mentioned in my thesis but didn't > end up in that patch, as it wasn't well tested. This was mainly for > delimited continuations and for the debugger. I'll share this soon in > a GitLab fork so it doesn't get lost. > > Andrea > > On 20 January 2018 at 16:06, Duncan Mak <duncanmak@gmail.com> wrote: >> Looks interesting. >> >> Is the work contained in only these two commits? >> >> https://gitlab.com/kashell/Kawa/commit/a8e678ebf7216e9fad9238e0b1c2442ea371c63c >> https://gitlab.com/kashell/Kawa/commit/f4228b57936de5a84dba0afcfac54196bec86fa4 >> >> >> Duncan. >> >> >> On Sat, Jan 20, 2018 at 1:46 AM, Per Bothner <per@bothner.com> wrote: >>> On 01/19/2018 04:48 PM, Duncan Mak wrote: >>>> >>>> Hello, >>>> >>>> I came across Andrea Bernardini's thesis called First-Class >>>> Continuations on the Java Virtual Machine: An Implementation within >>>> the Kawa Scheme Compiler just the other day. >>>> >>>> >>>> https://www.politesi.polimi.it/bitstream/10589/108685/3/2015_07_Bernardini.pdf >>>> >>>> What happened to that work, was it integrated into the mainline release of >>>> Kawa? >>> >>> >>> Sorry, no. Andrea's work is available in the 'callcc' branch, but it has not >>> been merged into master. Worse, updates to master have not been merged >>> into the callcc branch. >>> >>> It would be useful to at least update the callcc branch with recent changes, >>> and then test, evaluate, and benchmark it. If it is useful, it should be >>> merged in. >>> Even if it is slow, as long as it doesn't hurt the default behavior. It is >>> my fault >>> that hasn't been done, but there were always other things to do. >>> >>> Long time ago, I started on another implementation of continuations based on >>> switch statements. (Each continuation point would be associated with an >>> index, >>> and each function would start with a switch statement with jumps to the >>> continuation points. Capturing a continuation would essentially be saving >>> the >>> corresponding switch index.) Some of that code is still in Kawa, but >>> commented out. Following up on that idea might be more efficient. Which >>> isn't really a good excuse for not merging in Andrea's work. >>> >>> If someone is interested in following up on this work, that would be great. >>> -- >>> --Per Bothner >>> per@bothner.com http://per.bothner.com/ >> >> >> >> -- >> Duncan. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2018-02-21 0:21 ` Andrea Bernardini @ 2018-02-22 0:38 ` Duncan Mak 2021-05-01 16:15 ` Duncan Mak 0 siblings, 1 reply; 18+ messages in thread From: Duncan Mak @ 2018-02-22 0:38 UTC (permalink / raw) To: Andrea Bernardini; +Cc: Per Bothner, kawa mailing list Hello Per, https://gitlab.com/kashell/Kawa/merge_requests/22 should be ready for review now. You mentioned in your first reply that we should "test, evaluate, and benchmark it. If it's useful, it should be merged in." - do you have any suggestions for how I should proceed to get this merged in? You also mentioned that there's an idea on an alternative implementation technique based on switch statements - could we post the notes on https://gitlab.com/kashell/Kawa/issues, and perhaps someone else could tackle that? Duncan. On Tue, Feb 20, 2018 at 7:21 PM, Andrea Bernardini <andrebask@gmail.com> wrote: > Hi All, > Regarding delimited continuations, you can see the needed changes here > https://gitlab.com/andrebask/Kawa/compare/callcc...delimited-continuations > > Let me know if you are interested in this at all, shouldn't be > difficult to add this once Duncan's pull request is merged in. > > In the same fork there's also a branch with the debugger > implementation, however I'm not sure how useful that could be, it was > quite experimental > > Thanks, > Andrea > > On 20 January 2018 at 23:20, Andrea Bernardini <andrebask@gmail.com> wrote: >> Yep, that's it. The whole work was originally submitted as patch. >> >> It is also my fault If this was never merged into master. I remember >> that I started working on a switch-based variant of my work after >> getting some high level suggestions from Per. That turned out to be a >> fair amount of work and I didn't have much time, so I didn't manage to >> put together anything working. >> >> I also have some working code that I mentioned in my thesis but didn't >> end up in that patch, as it wasn't well tested. This was mainly for >> delimited continuations and for the debugger. I'll share this soon in >> a GitLab fork so it doesn't get lost. >> >> Andrea >> >> On 20 January 2018 at 16:06, Duncan Mak <duncanmak@gmail.com> wrote: >>> Looks interesting. >>> >>> Is the work contained in only these two commits? >>> >>> https://gitlab.com/kashell/Kawa/commit/a8e678ebf7216e9fad9238e0b1c2442ea371c63c >>> https://gitlab.com/kashell/Kawa/commit/f4228b57936de5a84dba0afcfac54196bec86fa4 >>> >>> >>> Duncan. >>> >>> >>> On Sat, Jan 20, 2018 at 1:46 AM, Per Bothner <per@bothner.com> wrote: >>>> On 01/19/2018 04:48 PM, Duncan Mak wrote: >>>>> >>>>> Hello, >>>>> >>>>> I came across Andrea Bernardini's thesis called First-Class >>>>> Continuations on the Java Virtual Machine: An Implementation within >>>>> the Kawa Scheme Compiler just the other day. >>>>> >>>>> >>>>> https://www.politesi.polimi.it/bitstream/10589/108685/3/2015_07_Bernardini.pdf >>>>> >>>>> What happened to that work, was it integrated into the mainline release of >>>>> Kawa? >>>> >>>> >>>> Sorry, no. Andrea's work is available in the 'callcc' branch, but it has not >>>> been merged into master. Worse, updates to master have not been merged >>>> into the callcc branch. >>>> >>>> It would be useful to at least update the callcc branch with recent changes, >>>> and then test, evaluate, and benchmark it. If it is useful, it should be >>>> merged in. >>>> Even if it is slow, as long as it doesn't hurt the default behavior. It is >>>> my fault >>>> that hasn't been done, but there were always other things to do. >>>> >>>> Long time ago, I started on another implementation of continuations based on >>>> switch statements. (Each continuation point would be associated with an >>>> index, >>>> and each function would start with a switch statement with jumps to the >>>> continuation points. Capturing a continuation would essentially be saving >>>> the >>>> corresponding switch index.) Some of that code is still in Kawa, but >>>> commented out. Following up on that idea might be more efficient. Which >>>> isn't really a good excuse for not merging in Andrea's work. >>>> >>>> If someone is interested in following up on this work, that would be great. >>>> -- >>>> --Per Bothner >>>> per@bothner.com http://per.bothner.com/ >>> >>> >>> >>> -- >>> Duncan. -- Duncan. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2018-02-22 0:38 ` Duncan Mak @ 2021-05-01 16:15 ` Duncan Mak 2021-05-01 18:45 ` Arvydas Silanskas 0 siblings, 1 reply; 18+ messages in thread From: Duncan Mak @ 2021-05-01 16:15 UTC (permalink / raw) To: Andrea Bernardini; +Cc: Per Bothner, kawa mailing list Hello all, I thought of this work last night and was reminded that the PR is still left hanging after 3 years. I wonder if it makes any sense to try to get this merged into the master branch after all this time. There's also the ongoing work from Project Loom at the JDK level: http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html and I wonder how that influences how continuations will be represented in Kawa in the future. Thoughts? Duncan. On Wed, Feb 21, 2018 at 7:37 PM Duncan Mak <duncanmak@gmail.com> wrote: > Hello Per, > > https://gitlab.com/kashell/Kawa/merge_requests/22 should be ready for > review now. > > You mentioned in your first reply that we should "test, evaluate, and > benchmark it. If it's useful, it should be merged in." - do you have > any suggestions for how I should proceed to get this merged in? > > You also mentioned that there's an idea on an alternative > implementation technique based on switch statements - could we post > the notes on https://gitlab.com/kashell/Kawa/issues, and perhaps > someone else could tackle that? > > > Duncan. > > On Tue, Feb 20, 2018 at 7:21 PM, Andrea Bernardini <andrebask@gmail.com> > wrote: > > Hi All, > > Regarding delimited continuations, you can see the needed changes here > > > https://gitlab.com/andrebask/Kawa/compare/callcc...delimited-continuations > > > > Let me know if you are interested in this at all, shouldn't be > > difficult to add this once Duncan's pull request is merged in. > > > > In the same fork there's also a branch with the debugger > > implementation, however I'm not sure how useful that could be, it was > > quite experimental > > > > Thanks, > > Andrea > > > > On 20 January 2018 at 23:20, Andrea Bernardini <andrebask@gmail.com> > wrote: > >> Yep, that's it. The whole work was originally submitted as patch. > >> > >> It is also my fault If this was never merged into master. I remember > >> that I started working on a switch-based variant of my work after > >> getting some high level suggestions from Per. That turned out to be a > >> fair amount of work and I didn't have much time, so I didn't manage to > >> put together anything working. > >> > >> I also have some working code that I mentioned in my thesis but didn't > >> end up in that patch, as it wasn't well tested. This was mainly for > >> delimited continuations and for the debugger. I'll share this soon in > >> a GitLab fork so it doesn't get lost. > >> > >> Andrea > >> > >> On 20 January 2018 at 16:06, Duncan Mak <duncanmak@gmail.com> wrote: > >>> Looks interesting. > >>> > >>> Is the work contained in only these two commits? > >>> > >>> > https://gitlab.com/kashell/Kawa/commit/a8e678ebf7216e9fad9238e0b1c2442ea371c63c > >>> > https://gitlab.com/kashell/Kawa/commit/f4228b57936de5a84dba0afcfac54196bec86fa4 > >>> > >>> > >>> Duncan. > >>> > >>> > >>> On Sat, Jan 20, 2018 at 1:46 AM, Per Bothner <per@bothner.com> wrote: > >>>> On 01/19/2018 04:48 PM, Duncan Mak wrote: > >>>>> > >>>>> Hello, > >>>>> > >>>>> I came across Andrea Bernardini's thesis called First-Class > >>>>> Continuations on the Java Virtual Machine: An Implementation within > >>>>> the Kawa Scheme Compiler just the other day. > >>>>> > >>>>> > >>>>> > https://www.politesi.polimi.it/bitstream/10589/108685/3/2015_07_Bernardini.pdf > >>>>> > >>>>> What happened to that work, was it integrated into the mainline > release of > >>>>> Kawa? > >>>> > >>>> > >>>> Sorry, no. Andrea's work is available in the 'callcc' branch, but it > has not > >>>> been merged into master. Worse, updates to master have not been > merged > >>>> into the callcc branch. > >>>> > >>>> It would be useful to at least update the callcc branch with recent > changes, > >>>> and then test, evaluate, and benchmark it. If it is useful, it should > be > >>>> merged in. > >>>> Even if it is slow, as long as it doesn't hurt the default behavior. > It is > >>>> my fault > >>>> that hasn't been done, but there were always other things to do. > >>>> > >>>> Long time ago, I started on another implementation of continuations > based on > >>>> switch statements. (Each continuation point would be associated with > an > >>>> index, > >>>> and each function would start with a switch statement with jumps to > the > >>>> continuation points. Capturing a continuation would essentially be > saving > >>>> the > >>>> corresponding switch index.) Some of that code is still in Kawa, but > >>>> commented out. Following up on that idea might be more efficient. > Which > >>>> isn't really a good excuse for not merging in Andrea's work. > >>>> > >>>> If someone is interested in following up on this work, that would be > great. > >>>> -- > >>>> --Per Bothner > >>>> per@bothner.com http://per.bothner.com/ > >>> > >>> > >>> > >>> -- > >>> Duncan. > > > > -- > Duncan. > -- Duncan. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-05-01 16:15 ` Duncan Mak @ 2021-05-01 18:45 ` Arvydas Silanskas 2021-05-01 19:06 ` Sudarshan S Chawathe 0 siblings, 1 reply; 18+ messages in thread From: Arvydas Silanskas @ 2021-05-01 18:45 UTC (permalink / raw) To: Duncan Mak; +Cc: Andrea Bernardini, kawa mailing list After skimming through the code, I don't see why not? If full continuations are optional and hidden behind a flag, it won't impact the software that cares about performance and has it turned off, and on flip side it will allow more portable r7rs code to be ran on kawa when desired and understanding the cost. Loom looks interesting, but (unless I missed it) doesn't give any sense of when we can expect it to be part of jvm distribution. Arvydas 2021-05-01, št, 20:20 Duncan Mak via Kawa <kawa@sourceware.org> rašė: > Hello all, > > I thought of this work last night and was reminded that the PR is still > left hanging after 3 years. > > I wonder if it makes any sense to try to get this merged into the master > branch after all this time. > > There's also the ongoing work from Project Loom at the JDK level: > http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html and I > wonder how that influences how continuations will be represented in Kawa in > the future. > > Thoughts? > > > Duncan. > > On Wed, Feb 21, 2018 at 7:37 PM Duncan Mak <duncanmak@gmail.com> wrote: > > > Hello Per, > > > > https://gitlab.com/kashell/Kawa/merge_requests/22 should be ready for > > review now. > > > > You mentioned in your first reply that we should "test, evaluate, and > > benchmark it. If it's useful, it should be merged in." - do you have > > any suggestions for how I should proceed to get this merged in? > > > > You also mentioned that there's an idea on an alternative > > implementation technique based on switch statements - could we post > > the notes on https://gitlab.com/kashell/Kawa/issues, and perhaps > > someone else could tackle that? > > > > > > Duncan. > > > > On Tue, Feb 20, 2018 at 7:21 PM, Andrea Bernardini <andrebask@gmail.com> > > wrote: > > > Hi All, > > > Regarding delimited continuations, you can see the needed changes here > > > > > > https://gitlab.com/andrebask/Kawa/compare/callcc...delimited-continuations > > > > > > Let me know if you are interested in this at all, shouldn't be > > > difficult to add this once Duncan's pull request is merged in. > > > > > > In the same fork there's also a branch with the debugger > > > implementation, however I'm not sure how useful that could be, it was > > > quite experimental > > > > > > Thanks, > > > Andrea > > > > > > On 20 January 2018 at 23:20, Andrea Bernardini <andrebask@gmail.com> > > wrote: > > >> Yep, that's it. The whole work was originally submitted as patch. > > >> > > >> It is also my fault If this was never merged into master. I remember > > >> that I started working on a switch-based variant of my work after > > >> getting some high level suggestions from Per. That turned out to be a > > >> fair amount of work and I didn't have much time, so I didn't manage to > > >> put together anything working. > > >> > > >> I also have some working code that I mentioned in my thesis but didn't > > >> end up in that patch, as it wasn't well tested. This was mainly for > > >> delimited continuations and for the debugger. I'll share this soon in > > >> a GitLab fork so it doesn't get lost. > > >> > > >> Andrea > > >> > > >> On 20 January 2018 at 16:06, Duncan Mak <duncanmak@gmail.com> wrote: > > >>> Looks interesting. > > >>> > > >>> Is the work contained in only these two commits? > > >>> > > >>> > > > https://gitlab.com/kashell/Kawa/commit/a8e678ebf7216e9fad9238e0b1c2442ea371c63c > > >>> > > > https://gitlab.com/kashell/Kawa/commit/f4228b57936de5a84dba0afcfac54196bec86fa4 > > >>> > > >>> > > >>> Duncan. > > >>> > > >>> > > >>> On Sat, Jan 20, 2018 at 1:46 AM, Per Bothner <per@bothner.com> > wrote: > > >>>> On 01/19/2018 04:48 PM, Duncan Mak wrote: > > >>>>> > > >>>>> Hello, > > >>>>> > > >>>>> I came across Andrea Bernardini's thesis called First-Class > > >>>>> Continuations on the Java Virtual Machine: An Implementation within > > >>>>> the Kawa Scheme Compiler just the other day. > > >>>>> > > >>>>> > > >>>>> > > > https://www.politesi.polimi.it/bitstream/10589/108685/3/2015_07_Bernardini.pdf > > >>>>> > > >>>>> What happened to that work, was it integrated into the mainline > > release of > > >>>>> Kawa? > > >>>> > > >>>> > > >>>> Sorry, no. Andrea's work is available in the 'callcc' branch, but it > > has not > > >>>> been merged into master. Worse, updates to master have not been > > merged > > >>>> into the callcc branch. > > >>>> > > >>>> It would be useful to at least update the callcc branch with recent > > changes, > > >>>> and then test, evaluate, and benchmark it. If it is useful, it > should > > be > > >>>> merged in. > > >>>> Even if it is slow, as long as it doesn't hurt the default behavior. > > It is > > >>>> my fault > > >>>> that hasn't been done, but there were always other things to do. > > >>>> > > >>>> Long time ago, I started on another implementation of continuations > > based on > > >>>> switch statements. (Each continuation point would be associated > with > > an > > >>>> index, > > >>>> and each function would start with a switch statement with jumps to > > the > > >>>> continuation points. Capturing a continuation would essentially be > > saving > > >>>> the > > >>>> corresponding switch index.) Some of that code is still in Kawa, > but > > >>>> commented out. Following up on that idea might be more efficient. > > Which > > >>>> isn't really a good excuse for not merging in Andrea's work. > > >>>> > > >>>> If someone is interested in following up on this work, that would be > > great. > > >>>> -- > > >>>> --Per Bothner > > >>>> per@bothner.com http://per.bothner.com/ > > >>> > > >>> > > >>> > > >>> -- > > >>> Duncan. > > > > > > > > -- > > Duncan. > > > > > -- > Duncan. > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-05-01 18:45 ` Arvydas Silanskas @ 2021-05-01 19:06 ` Sudarshan S Chawathe 2021-05-01 20:38 ` Per Bothner 0 siblings, 1 reply; 18+ messages in thread From: Sudarshan S Chawathe @ 2021-05-01 19:06 UTC (permalink / raw) To: Arvydas Silanskas; +Cc: Duncan Mak, kawa mailing list Hopefully this isn't considered noise but I thought I'd add a brief note as a Kawa user: It would be really great to have support for first-class continuations. I recall several instances when I wanted to use some portable library (typically from snow-fort.org) and hit a roadblock due to continuations. And similarly with some SRFI sample implementations. A question to the implementation-savvy: Would the only downside of enabling first-class continuations (assuming they have been implemented of course) be potentially lower performance? Or would there be some compatibility issues with other JVM languages and libraries? For instance, would using some Java library such as okhttp pose any issues other than a potential modest performance hit? In any case, thanks to all involved in this effort. Regards, -chaw ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-05-01 19:06 ` Sudarshan S Chawathe @ 2021-05-01 20:38 ` Per Bothner 2021-06-09 9:04 ` Arvydas Silanskas 0 siblings, 1 reply; 18+ messages in thread From: Per Bothner @ 2021-05-01 20:38 UTC (permalink / raw) To: kawa It is indeed a shame that this has been languishing so long. However, we need someone to drive it - not me. It is not just a matter of merging in the code. We need someone who is willing to study and understand the code, test it (including writing testcases), and measure the performance. The implementation is I believe functional (conceptually - things may have broken over the years), but I suspect it is not very efficient. Still, if it works correctly (which requires testing by someone who understands continuations better than I do), one can always work on performance later. There is some old code dependent on the usingSPSStyle method that could potentially be more efficient. It is based on using the JVM tableswitch instruction, so it might be more efficient - at least worth studying for ideas. On the other hand, using MethodHandle to call all the stub procedures that result from CPS conversion might be better style, and would probably be more elegant and fit better with the existing framework: Basically have CALL_WITH_CONTINUATIONS build on the CALL_WITH_TAILCALLS framework. which uses MethodHandles. Basically, I'm hoping for someone willing who understands and wants to use continuations, and who is willling to put in the time to understand the callcc branch, how CALL_WITH_TAILCALLS uses MethodHandles, the JVM, and the ideas behind old commented-out usingSPSStyle code. That's a tall order - but you would learn a lot! Using Project Loom would almost certainly be more efficient and simpler to code - but I think it will take a long time before Loom is useful to us. My impression is Loom is focusing initially on low-overhead threads ("fibers"), which can use useful for some call/cc use-cases (such as co-routines and "async" programing - or more generally "single-use" continuations). Delimited continuations may take longer - and even for low-overhead threads I haven't seen any timeframe. > Or would there be some > compatibility issues with other JVM languages and libraries? I suspect if you create a continuation, call some Java methods (or Kawa code that has not been compiled with the necessary switches), and then invoke the continuation, I doubt it will work, at least in general. -- --Per Bothner per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-05-01 20:38 ` Per Bothner @ 2021-06-09 9:04 ` Arvydas Silanskas 2021-06-09 23:27 ` Per Bothner 0 siblings, 1 reply; 18+ messages in thread From: Arvydas Silanskas @ 2021-06-09 9:04 UTC (permalink / raw) To: Per Bothner; +Cc: kawa mailing list Has anyone taken up on this? If not, I'll give it a try. 2021-05-02, sk, 00:50 Per Bothner <per@bothner.com> rašė: > It is indeed a shame that this has been languishing so long. > However, we need someone to drive it - not me. > > It is not just a matter of merging in the code. We need someone who is > willing to study and understand the code, test it (including writing > testcases), > and measure the performance. > > The implementation is I believe functional (conceptually - things may have > broken over the years), but I suspect it is not very efficient. Still, > if it works correctly (which requires testing by someone who understands > continuations better than I do), one can always work on performance later. > > There is some old code dependent on the usingSPSStyle method that could > potentially be more efficient. It is based on using the JVM tableswitch > instruction, so it might be more efficient - at least worth studying for > ideas. > > On the other hand, using MethodHandle to call all the stub procedures > that result from CPS conversion might be better style, and would probably > be more elegant and fit better with the existing framework: > Basically have CALL_WITH_CONTINUATIONS build on the CALL_WITH_TAILCALLS > framework. which uses MethodHandles. > > Basically, I'm hoping for someone willing who understands and wants to > use continuations, and who is willling to put in the time to understand > the callcc branch, how CALL_WITH_TAILCALLS uses MethodHandles, the JVM, > and the ideas behind old commented-out usingSPSStyle code. > > That's a tall order - but you would learn a lot! > > Using Project Loom would almost certainly be more efficient and > simpler to code - but I think it will take a long time before Loom > is useful to us. My impression is Loom is focusing initially on > low-overhead > threads ("fibers"), which can use useful for some call/cc use-cases > (such as co-routines and "async" programing - or more generally > "single-use" > continuations). Delimited continuations may take longer - and even > for low-overhead threads I haven't seen any timeframe. > > > Or would there be some > > compatibility issues with other JVM languages and libraries? > > I suspect if you create a continuation, call some Java methods > (or Kawa code that has not been compiled with the necessary switches), > and then invoke the continuation, I doubt it will work, at least in > general. > -- > --Per Bothner > per@bothner.com http://per.bothner.com/ > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-06-09 9:04 ` Arvydas Silanskas @ 2021-06-09 23:27 ` Per Bothner 2021-08-08 14:29 ` Arvydas Silanskas 0 siblings, 1 reply; 18+ messages in thread From: Per Bothner @ 2021-06-09 23:27 UTC (permalink / raw) To: Arvydas Silanskas; +Cc: kawa mailing list On 6/9/21 2:04 AM, Arvydas Silanskas wrote: > Has anyone taken up on this? If not, I'll give it a try. As far as I know, nobody has stepped up, or is working in this. Great if you want to step up. Do read my previous message carefully - though note that 'usingSPSStyle' should be 'usingCPStyle'. -- --Per Bothner per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-06-09 23:27 ` Per Bothner @ 2021-08-08 14:29 ` Arvydas Silanskas 2021-08-08 15:53 ` Andrea Bernardini 2021-08-08 23:52 ` Per Bothner 0 siblings, 2 replies; 18+ messages in thread From: Arvydas Silanskas @ 2021-08-08 14:29 UTC (permalink / raw) To: Per Bothner; +Cc: kawa mailing list I merged and got the original code mostly working (leaving optimization refactoring for later), but I ran into one major issue when creating benchmarks. It seems calling kawa from java gets conceptually broken if kawa classes are used directly. New call/cc requires top level handling loop, which gets bypassed if I instantiate and use directly, like ``` var foo = (FooInterface) Class.forName("Foo").newInstance(); foo.bar(); ``` where FooInterface is an interface written in java, and Foo is a class created by `define-simple-class` on kawa side which specifies said interface as one of its supers. * Am I using the recommended approach for java -> kawa interaction? * If yes to the first question, do we strongly care that this type of calling gets broken as a compromise? After all the (optionally enabled, by default disabled) full continuations will weaken interop anyway, so maybe this is not worth trying to save. I'm not certain what a fix would be, maybe some sort of custom equivalent to Class.forName, which would return a proxied class with the handling loop attached to the methods. * The points about using CPStyle / CALL_WITH_TAILCALLS from what I can understand are purely regarding optimizations, right? Or do you think that refactored code using those approaches would also solve the problem above? 2021-06-10, kt, 02:27 Per Bothner <per@bothner.com> rašė: > > > On 6/9/21 2:04 AM, Arvydas Silanskas wrote: > > Has anyone taken up on this? If not, I'll give it a try. > > As far as I know, nobody has stepped up, or is working in this. > Great if you want to step up. > > Do read my previous message carefully - though note that > 'usingSPSStyle' should be 'usingCPStyle'. > -- > --Per Bothner > per@bothner.com http://per.bothner.com/ > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-08-08 14:29 ` Arvydas Silanskas @ 2021-08-08 15:53 ` Andrea Bernardini 2021-08-08 23:52 ` Per Bothner 1 sibling, 0 replies; 18+ messages in thread From: Andrea Bernardini @ 2021-08-08 15:53 UTC (permalink / raw) To: Arvydas Silanskas; +Cc: Per Bothner, kawa mailing list Hi Arvydas, As far as I remember we never took into account interaction of call/cc outside of scheme code. The top level handler is added to the top level ModuleExp when the scheme code is compiled. When you define a class I don't think it's wrapped into a ModuleExp (I'm guessing here you are calling call/cc inside a method in Foo). A practical way to allow that could be to use a delimited continuation as explained here: https://andrebask.github.io/thesis/#other-control-operators-delimited-continuations On Sun, 8 Aug 2021, 3:29 pm Arvydas Silanskas via Kawa, <kawa@sourceware.org> wrote: > I merged and got the original code mostly working (leaving optimization > refactoring for later), but I ran into one major issue when creating > benchmarks. It seems calling kawa from java gets conceptually broken if > kawa classes are used directly. New call/cc requires top level handling > loop, which gets bypassed if I instantiate and use directly, like > > ``` > var foo = (FooInterface) Class.forName("Foo").newInstance(); > foo.bar(); > ``` > > where FooInterface is an interface written in java, and Foo is a class > created by `define-simple-class` on kawa side which specifies said > interface as one of its supers. > > * Am I using the recommended approach for java -> kawa interaction? > * If yes to the first question, do we strongly care that this type of > calling gets broken as a compromise? After all the (optionally enabled, by > default disabled) full continuations will weaken interop anyway, so maybe > this is not worth trying to save. I'm not certain what a fix would be, > maybe some sort of custom equivalent to Class.forName, which would return a > proxied class with the handling loop attached to the methods. > * The points about using CPStyle / CALL_WITH_TAILCALLS from what I can > understand are purely regarding optimizations, right? Or do you think that > refactored code using those approaches would also solve the problem above? > > > 2021-06-10, kt, 02:27 Per Bothner <per@bothner.com> rašė: > > > > > > > On 6/9/21 2:04 AM, Arvydas Silanskas wrote: > > > Has anyone taken up on this? If not, I'll give it a try. > > > > As far as I know, nobody has stepped up, or is working in this. > > Great if you want to step up. > > > > Do read my previous message carefully - though note that > > 'usingSPSStyle' should be 'usingCPStyle'. > > -- > > --Per Bothner > > per@bothner.com http://per.bothner.com/ > > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-08-08 14:29 ` Arvydas Silanskas 2021-08-08 15:53 ` Andrea Bernardini @ 2021-08-08 23:52 ` Per Bothner 2021-08-09 19:41 ` Per Bothner 1 sibling, 1 reply; 18+ messages in thread From: Per Bothner @ 2021-08-08 23:52 UTC (permalink / raw) To: Arvydas Silanskas; +Cc: kawa mailing list On 8/8/21 7:29 AM, Arvydas Silanskas wrote: > I merged and got the original code mostly working (leaving optimization refactoring for later), Cool. > var foo = (FooInterface) Class.forName("Foo").newInstance(); > foo.bar(); > ``` > > where FooInterface is an interface written in java, and Foo is a class created by `define-simple-class` on kawa side which specifies said interface as one of its supers. > > * Am I using the recommended approach for java -> kawa interaction? For the simple case. But clearly it might not work in general. Does what you're trying to work when Foo is compiled with --full-tailcalls ? The latter also makes use of a top-level handling loop, but there are automatic "bridges" between the two styles of functions (see CallContext.runUntilDone). Based on a trivial test, a bar method in a Foo class under --full-tailcall just becomes a plain Java method (without tail-call support). > * If yes to the first question, do we strongly care that this type of calling gets broken as a compromise? After all the (optionally enabled, by default disabled) full continuations will weaken interop anyway, so maybe this is not worth trying to save. I'm not certain what a fix would be, maybe some sort of custom equivalent to Class.forName, which would return a proxied class with the handling loop attached to the methods. I think its ok to require people to write wrapper code in Scheme when generating "simple" classes. > * The points about using CPStyle / CALL_WITH_TAILCALLS from what I can understand are purely regarding optimizations, right? Or do you think that refactored code using those approaches would also solve the problem above? Implementing CPStyle / CALL_WITH_CONTINUATIONS is mostly performance. However, since CALL_WITH_CONTINUATIONS is sort of an extension of CALL_WITH_TAILCALLS, I think the whole system would be better integrated. Specifically having a single CallContext.runUntilDone with that handles both continuations and tail-calls would be preferable. (I think I haven't looked much at this code in a while.) -- --Per Bothner per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-08-08 23:52 ` Per Bothner @ 2021-08-09 19:41 ` Per Bothner 2022-12-07 23:42 ` Duncan Mak 0 siblings, 1 reply; 18+ messages in thread From: Per Bothner @ 2021-08-09 19:41 UTC (permalink / raw) To: kawa A suggestion: Polish and check in the code in the calcc branch. Then change the interface so it is compatible that the tail-call API. Specifically change the generated "fragments" so each looks like: static Object stubNN(Procedure proc, CallContext ctx) throws Throwable) { ... } and call each fragment using MethodHandle#invokeExact. Of course this is not trivial: The person(s) doing this have to understand not just logic of callcc changes but also how applyToConsumerMethod and CallContext etc work, before they can synthesize them. -- --Per Bothner per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2021-08-09 19:41 ` Per Bothner @ 2022-12-07 23:42 ` Duncan Mak 2022-12-09 10:53 ` Arvydas Silanskas 0 siblings, 1 reply; 18+ messages in thread From: Duncan Mak @ 2022-12-07 23:42 UTC (permalink / raw) To: Per Bothner; +Cc: kawa [-- Attachment #1: Type: text/plain, Size: 951 bytes --] There's a new SRFI effort on refining the continuation API: SRFI 226: Control Features (schemers.org) <https://srfi.schemers.org/srfi-226/srfi-226.html> It'd be interesting to look into implementing this SRFI for Kawa Scheme. On Mon, Aug 9, 2021 at 3:42 PM Per Bothner <per@bothner.com> wrote: > A suggestion: Polish and check in the code in the calcc branch. > Then change the interface so it is compatible that the tail-call API. > Specifically change the generated "fragments" so each looks like: > > static Object stubNN(Procedure proc, CallContext ctx) throws Throwable) > { ... } > > and call each fragment using MethodHandle#invokeExact. > > Of course this is not trivial: The person(s) doing this have to understand > not just logic of callcc changes but also how applyToConsumerMethod and > CallContext etc work, before they can synthesize them. > -- > --Per Bothner > per@bothner.com http://per.bothner.com/ > -- Duncan. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: First-class continuations in Kawa 2022-12-07 23:42 ` Duncan Mak @ 2022-12-09 10:53 ` Arvydas Silanskas 0 siblings, 0 replies; 18+ messages in thread From: Arvydas Silanskas @ 2022-12-09 10:53 UTC (permalink / raw) To: Duncan Mak; +Cc: Per Bothner, kawa [-- Attachment #1: Type: text/plain, Size: 1379 bytes --] Continuations are indeed interesting, but hard to implement unfortunately. As a recap of my merging attempts; base call/cc worked, but I got stuck at figuring how to get dynamic-wind and other extent-aware features working, and unfortunately had to stash it 2022-12-08, kt, 01:43 Duncan Mak via Kawa <kawa@sourceware.org> rašė: > There's a new SRFI effort on refining the continuation API: > > SRFI 226: Control Features (schemers.org) > <https://srfi.schemers.org/srfi-226/srfi-226.html> > > It'd be interesting to look into implementing this SRFI for Kawa Scheme. > > On Mon, Aug 9, 2021 at 3:42 PM Per Bothner <per@bothner.com> wrote: > > > A suggestion: Polish and check in the code in the calcc branch. > > Then change the interface so it is compatible that the tail-call API. > > Specifically change the generated "fragments" so each looks like: > > > > static Object stubNN(Procedure proc, CallContext ctx) throws > Throwable) > > { ... } > > > > and call each fragment using MethodHandle#invokeExact. > > > > Of course this is not trivial: The person(s) doing this have to > understand > > not just logic of callcc changes but also how applyToConsumerMethod and > > CallContext etc work, before they can synthesize them. > > -- > > --Per Bothner > > per@bothner.com http://per.bothner.com/ > > > > > -- > Duncan. > ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-12-09 10:53 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-20 0:49 First-class continuations in Kawa Duncan Mak 2018-01-20 6:47 ` Per Bothner 2018-01-20 16:07 ` Duncan Mak 2018-01-20 23:20 ` Andrea Bernardini 2018-02-21 0:21 ` Andrea Bernardini 2018-02-22 0:38 ` Duncan Mak 2021-05-01 16:15 ` Duncan Mak 2021-05-01 18:45 ` Arvydas Silanskas 2021-05-01 19:06 ` Sudarshan S Chawathe 2021-05-01 20:38 ` Per Bothner 2021-06-09 9:04 ` Arvydas Silanskas 2021-06-09 23:27 ` Per Bothner 2021-08-08 14:29 ` Arvydas Silanskas 2021-08-08 15:53 ` Andrea Bernardini 2021-08-08 23:52 ` Per Bothner 2021-08-09 19:41 ` Per Bothner 2022-12-07 23:42 ` Duncan Mak 2022-12-09 10:53 ` Arvydas Silanskas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).