Parallella Community

Hi,

I've created repos for two OpenJDK projects extensions:
https://bitbucket.org/michal_warecki/graal-epiphany
https://bitbucket.org/michal_warecki/su ... v-epiphany

Best,
Michał

Hi Michal,

I am also interested to see Java running on the Epiphany cores.

What happens if in your forEach lambda expression another function is called? Is function executed on ARM core or on the Epiphany core. If the function is executed on the ARM core then the resources will be hoping from epiphany core -> ARM core -> epiphany core once or several times probably slowing down the cores and filling the eMesh network.
If the function is executed on the Epiphany core what happens if other bigger libraries are used.

It would be nice to see the epiphany cores to execute the normal threads (each executed servlet, map/reduce of hadoop) while the main thread, gui thread, gc thread would be executed on the ARM cores and also all the intensive IO processes (disk IO, TCP/IP stack) and error handling would also run on the ARM cores. If that would be supported the adoption of epiphany for web servers and data storage/databases/cloud and business applications would skyrocket. The Epiphany cores would still run the libraries, but the libraries would be loaded in the bigger SDR memory. The hard part would be the balancing act of execution of the jvm machine on the epiphany cores.
It would be nice to see write once, run everywhere even on the epiphany core.

I will probably first try to run openCL on the board - will see if jogamp, javacl or jocl work on the Epiphany cores.

But I think It would be useful to create an API framework which would directly use the sdk framework through JNI. The framework could use predefined processes which would shield the user from writing direct code for the cores and would also handle the concurrency correctly.

I don't have the overview yet, found out about parallella two weeks ago, still reading the docs (epiphanny reference files).
I will also have to look into the graal and sumatra projects. I see it won't be easy, but through the process we will learn a lot.

I am also waiting for the parallella board.

Best,
Tomo

Count me in on the interested stakes here. I'm pretty familiar & experienced with most of the technlogy involved ... except compilers. I'm not sure time will let me help much mind you but i'll be interested to see it progress. Definitely a major undertaking.

I'm still pretty much waiting for the jdk8 GA release before delving into lambdas myself (and personally i'm happy enough with C/ASM or opencl from Java) but they look like a promising way for "normal" programmers to exploit concurrent accelerators or and/or SIMD units in a way that non-jvm languages can't easily replicate.

Hi,

It would be great if we could get Hera JVM to work on the Epiphany cores (+ARM).

I went looking which engine should we adopt:
http://en.wikipedia.org/wiki/Comparison ... l_machines

Taurus JVM http://www.tsac.co.uk/javavm/index.php
Avian http://oss.readytalk.com/avian/index.html
Jikes RVM http://jikesrvm.org/
Jelatine JVM http://jelatine.sourceforge.net/

Taurus and Jelatine are interesting because they use little memory, Jelatine requires as little as 32 KiB of RAM.

Avian, Jikes have more permissive licenses than GPL.
Taurus has not been worked on for years as I can see from uploaded files.
Avian and Jikes have active repositories.

It would probably be overkill to try to implement the complete openJDK on the epiphany cores, therefore it would be better if at first we would implement only a small jvm and then look into Hera JVM. The question is what implementation would be used as a starting point.

I am strongly leaning towards Avian which can be compiled as standalone, be used with openJDK and has some kind of support for Android.
Hera JVM is using Jikes as its VM.
Jikes supports GNU Classpath, openJDK is not yet fully supported, supports Apache Harmoiny.

I hope I am not starting war about which JVM should be implemented. Anyone would probably be good as long as it stays in the memory footprint of Epiphany core.

Michal Warecki cloned the graal and sumatra projects, but I am not sure if that is what is needed.
One possibility would be creating clean implementation from scratch, but I would prefer more an implementation which leans a bit on Avian or Jikes.

Sorry, I was on vacations.

OpenJDK support has the highest priority because it contains projects that fits Epiphany support (Graal, Sumatra). Another reason is that 99% of JVM instances are OpenJDK/Oracle hotspot.

I finished definition of Epiphany architecture in Graal. This week I'm going to finish article and start work on LIR in Graal. Stay tuned.
Next month I'll have much more time for this project.

@Tomo - I don't think that this would work well (because of synchronization points). Firstly we need to be able to execute very simple blocks of code with algorithms prepared for parallelization.

Best,
Michał

Michal: I agree best bet is on OpenJDK.

I contacted Ross McIlroy and he agreed to share his code on github: https://github.com/rmcilroy/HeraJVM
Thanks Ross.
But the code was made on the old Jikes RVM( version 2.9.3) and the second problem is that Jikes RVM does not run on ARM processors. But there might be some precious gems to pick out.