* 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).