mlvm build with coroutines -- but coro tests fail
Rémi Forax
forax at univ-mlv.fr
Tue May 3 14:22:10 PDT 2011
On 05/03/2011 10:53 PM, Charles Oliver Nutter wrote:
> Brainstorming coro package names...
>
> java.lang.invoke isn't bad, perhaps, but it is a different form of invocation than invokedynamic.
>
> This is a core JVM feature, so something under java.lang seems appropriate in any case...
>
> java.lang.coroutine (or coro) is maybe too specific?
>
> How far off would it be to call coroutines "fibers" outright? Perhaps fiber does not sufficiently cover all uses of coroutines.
>
> I'll throw out java.lang.fiber as an option.
>
> java.lang.stack would cover the wider uses of stack-swapping, stack-memoizing, and microthreading happening here...
>
> If the primary classes for coro lived directly under java.lang then other lang classes could depend on them, like Thread, and every package that deals with Runnable could depend on Coroutine the same way.
why not java.lang ?
as you said, coroutines have strong links with java.lang classes.
> Perhaps we should bite the bullet and use this as an opportunity to introduce java.lang.fp or java.lang.function, to host this and other future utilities that might be useful to functional programming? I could see tail-call related utilities fitting there as well, and any classes in the system (like Executors, etc) could start to be *consistent* with external package dependencies.
tailcall doesn't require any API support.
Also as lambda is currently specified, there is no function type thus no
need of packages like java.lang.function.
But there is a good chance that a package under java.util will be
introduced to add lambda support to collection.
> Just a few thoughts. The justifications for not introducing java.dyn seem applicable to this situation.
>
> - Charlie (mobile)
Rémi
> On May 3, 2011, at 10:42, Lukas Stadler<lukas.stadler at jku.at> wrote:
>
>> Ah - since invokedynamic doesn't use the java.dyn package any more the
>> necessary build infrastructure went missing... I just re-added it.
>> One of the tests still fails, but at least it compiles...
>>
>> - Lukas
>>
>> On 05/02/2011 05:27 PM, Stephen Bannasch wrote:
>>> I've uploaded a build of mlvm with coro enabled:
>>>
>>> http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-mlvm-2011_05_02.tar.gz
>>>
>>> but running these tests fail: jdk/test/java/dyn/CoroutineTest.java
>>>
>>> #section:compile
>>> ----------messages:(3/175)----------
>>> command: compile /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/dyn/CoroutineTest.java
>>> reason: .class file out of date or does not exist
>>> elapsed time (seconds): 0.778
>>> ----------System.out:(1/101)----------
>>> OpenJDK 64-Bit Server VM warning: Use -XX:+UnlockDiagnosticVMOptions before EnableInvokeDynamic flag
>>> ----------System.err:(172/7390)----------
>>> /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/dyn/CoroutineTest.java:33: error: package java.dyn does not exist
>>> import java.dyn.Coroutine;
>>> ^
>>> /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/dyn/CoroutineTest.java:34: error: package java.dyn does not exist
>>> import java.dyn.AsymCoroutine;
>>> ^
>>> /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/dyn/CoroutineTest.java:54: error: cannot find symbol
>>> Coroutine coro = new Coroutine() {
>>> ^
>>> symbol: class Coroutine
>>> location: class CoroutineTest
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
More information about the mlvm-dev
mailing list