We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Just-in-Time Programming

00:00

Formal Metadata

Title
Just-in-Time Programming
Subtitle
Considering Liveness in Java
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
A few thoughts on the trials and tribulations of building a just-in-time programming system in Java. But wait, isn’t it a JIT-compiled language anyway? Job done … next talk … no, wait... Java may have JIT-compiled bytecode, and that makes it a useful tool for this endeavour, but that doesn’t get us from source code to running code. And anyway, there’s far more to a useful just-in-time programming system than just getting code running. PraxisLIVE is a hybrid-visual IDE for live programming. At its heart is PraxisCORE, a forest-of-actors runtime for real-time programming, bringing aspects of Erlang, SmallTalk and Extempore into the Java world. We’ll explore the inter-relationship of liveness and feedback between runtimes and tools … possibly with the help of a few bleepy noises!
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
Java appletComputer programmingCompilation albumJust-in-Time-CompilerInteractive televisionSoftware developerTape driveComputing platformSystem programmingPhysical computingDigital signal processorHypermediaParallel portData compressionSupersonic speedIntegrated development environmentNumerical analysisTime domainAerodynamicsTask (computing)Immersion (album)ForestCodeArchitectureDataflowMereologyMultiplication signHybrid computerVisualization (computer graphics)Just-in-Time-CompilerSystem programmingReal-time operating systemMilitary baseCodeErlang distributionInteractive televisionIntegrated development environmentService (economics)Numbering schemeDialectJava appletComputer programMathematicsMetaprogrammierungType theoryForm (programming)PhysicalismArtificial lifeSemiconductor memoryGoodness of fitSpeicherbereinigungDemo (music)Run time (program lifecycle phase)Formal languageDataflowCore dumpData compressionScaling (geometry)Computer architectureSoftware developerVideo gameBitMusical ensembleHypermediaDemosceneProgramming languageWeb applicationForestComputer animation
Computer programSystem programmingRange (statistics)Connectivity (graph theory)Computer animationLecture/Conference
System programmingCore dump
Right angleGroup actionSystem programmingCategory of beingRange (statistics)Zoom lensType theoryMessage passingCodeProcess (computing)Graphics libraryFunctional programmingSource code
Type theorySystem programmingVirtual machineSystem callEntire functionIntegrated development environmentGroup actionRun time (program lifecycle phase)SoftwareFlow separationConnected spaceMathematicsSource code
Standard deviationGraph (mathematics)Service (economics)Real-time operating systemProcess (computing)Interactive televisionCodeComputer fileSystem programmingConfiguration spaceDifferent (Kate Ryan album)Category of beingSpeicherbereinigungField (computer science)Graph (mathematics)Virtual machineForestString (computer science)ChainParameter (computer programming)SynchronizationComputer animation
Slide ruleCodeRun time (program lifecycle phase)Computer animation
Execution unitInclusion mapState of matterIdentity managementJava appletObject-oriented programmingCodeEuclidean vectorContext awarenessMessage passingService (economics)CompilerInterpreter (computing)Social classBytecodeRead-only memorySource codeBootingIterationRepetitionGastropod shelloutputFunction (mathematics)String (computer science)Inheritance (object-oriented programming)ForestComputer architectureState of matterSingle-precision floating-point formatString (computer science)Generic programmingThread (computing)Term (mathematics)Configuration spaceProcess (computing)CodeService (economics)Compilation albumoutputJava appletMessage passingContext awarenessIterationSemiconductor memorySocial classBootingIdentity managementConnectivity (graph theory)Data typeCompilerObject-oriented programmingError messageConstructor (object-oriented programming)Heegaard splittingAreaBytecodeSystem programmingMultiplication signFile systemBitInjektivitätExtension (kinesiology)ChainContent (media)Right angleType theoryDatabase transactionMathematicsVideo gameForm (programming)Integrated development environmentNetwork topologyRange (statistics)MereologyImage registrationConnected spaceEndliche ModelltheorieEncapsulation (object-oriented programming)Flash memoryCategory of beingCartesian coordinate systemGraph (mathematics)Scheduling (computing)Execution unitPerturbation theoryComputer animationLecture/Conference
Generic programmingDemo (music)BlogGraph (mathematics)Directed graphProxy serverMessage passingConnectivity (graph theory)Point (geometry)ImplementationTelecommunicationType theoryComputer programEmailGraphical user interfaceMusical ensembleJava appletMoment (mathematics)SynchronizationMultiplication signBinary codeData conversionPlastikkarteMechanism designIntegrated development environmentProjective planeGame controllerCartesian coordinate systemSystem programmingControl flowBitWeightOpen setCausalityRevision controlQueue (abstract data type)MultiplicationShared memoryCore dumpDifferent (Kate Ryan album)Social classFunctional programmingThread (computing)BlogOpen sourceRadical (chemistry)Interactive televisionComputer animation
Open sourcePoint cloudFacebookComputer animationLecture/Conference
Transcript: English(auto-generated)
Ok, so my talk's going to be on just-in-time programming. Hopefully this will go alright. I've written this in the last two days, having been asked to fill in a slot. I think
it can fit into 20 minutes, give me a good way through here. So, just-in-time programming. We're going to talk about just-in-time programming in Java. Java is just-in-time compiled. The end. Ok. What's Java C for? So, we're not going to be talking about just-in-time
compilation, but looking at how liveness in programming languages and tools, how we can get from working with source code into something that's running with as low latency as possible. Or coding at the speed of type. So, my name's Neil C. Smith. I live in Oxford
in the UK. I'm a developer working with Flos for 15, 20 years. The 15's there because that's how long I've been doing it professionally in one form or another. I've done my duties, I've built enough web apps and services. Luckily not doing that anymore.
I now do contracting around lots of niche and interesting and fun things around things like real-time systems, real-time programming, media stuff, a lot of stuff with Gstreamer and interaction with the JVM. Alongside all of that, I've occasionally had some time
to make some interesting and fun things as an artist. Again, mostly using Java, some fun interactive things outdoors, so at a larger scale, and some embedded little things from museums at a slightly smaller scale. And, yeah, occasionally I go into nightclubs and make breakbeat music by writing Java lambdas, because why wouldn't you? So, talking about
liveness in programming. There's a thing called live coding, which you may or may not have heard of. People go into clubs, like I say, and do visuals, audio, there's people. Why would you not code in Lisp to make visuals? And there are tools that are
things like Sonic Pi by Sam Aaron, that are, is a Ruby-based DSL for doing live programming specifically of music. What interests me particularly is these two worlds of live coding and interactive programming. If you look at the Wikipedia definitions
of both, you'll see that they go, oh, this is not this, and this is not this, and yet every example is the same. So, what kind of interests me is how we make general purpose live programming environments. And one of the environments that comes out of a more live coding scene that's becoming more generic is called Extemporary by Andrew Sorenson,
which includes a language called XTLang, which is a scheme dialect for coding natively through LLVM. It's not garbage collected. It has ways of functionally doing memory regions, things like that, designed for low latency systems programming. Then, if we're talking
about liveness and reasons for liveness, it's about exploring code bases. So, you've got things like Ferro, which is a contemporary take on Smalltalk. Obviously, Java was partly influenced by Smalltalk. Maybe we haven't taken everything we could do yet. And so, this is kind of interesting to look at evolving tools, which is kind of how, hopefully, this
talk fits into this room. And also, you've got systems like Erlang that allow you to hot-swap code while it's running. And these two things, in my mind, are very interrelated. So I initially, in that artist-hobby obsession part of life, was writing a live hybrid
visual IDE called Praxis Live. At the heart of it is a system called Praxis Core, which is basically a library-codable actor system. I say that was in kind of that one, and this is starting now to bring the two sides of my life together, which is the
fun bits and the actually making the living bits. So, I'm only going to look at Praxis Core. Forest of Actors runtime. We'll look a little bit at that, what that means. It's designed for hot-code relating in real-time systems, or real-time, it's Java, but, you know, soft real-time systems. And explore how its architecture supports this idea of
liveness. And there are lots of ways we might want liveness. To explore code we're working with, to explore the behavior of a system we're working with, to understand the changes that we make as a system, and to immediately see their reactions, say if you're working with something that has a physical reaction, physical computing, to change code and see literally, without very little latency, what the changes
have. To be able to code at the flow of thought, not waiting two minutes for your thing to reload, metaprogram. Metaprogram code is out. Or hot-patching. And because it's fun. So, quick demo of some of the features and to show you what I'm
talking about. So we're going to access live here. Hopefully working. Yeah, there you are. Just live video, you know. Prove it's live. Hello world. So, we'll ignore that
tab for now. So, we have what is probably quite familiar to you as a node based graph. You've seen node based programming systems before, I'm sure. We have a range of components here that we can change properties of. Exactly, we're
sending, we've got a camera in there, we're sending some text to it. Hello world. What is different in this system? So, each of these represents one of the actors in the underlying Praxis core system. Is that we can right-click edit code. Let's zoom in a little bit. So, this is wrapping a graphics library in this
particular example called processing. Very simple API for doing drawing. So, I can just write some more code in here. So, I've typed some code. As soon as I hit save you'll see it flash and it's immediately injected into the system. So,
another thing I can do is, so we can make something that interacts to something. You'll see up here I've got some annotated fields over on the right
top right hand side the various properties. So, this actor system has specific types of messaging or conventions basically for messaging. So, we have a properties is one convention. They're also what you know typical function and triggering actions so that you'd be more familiar with in their
typical actor system. So, how do I add a property here? We just annotate something. We can give it a range here and we'll call it size and then down here I can
this and so immediately I have this ability to interact with this. Bearing in mind one thing we'll get on to that this is system the IDE and the runtime are in separate processes. So, this isn't this could be running on a separate machine entirely. So, we're flinging things automatically across a network
connection. So, we've done that. The other thing we can do is I'll change that into a property type. I need to get out of here and I'll do a quick call this
blip. We'll make a little action and we'll take size and we'll do zero. Okay. So, I've added a
little method into there that's just going to animate this size. We've now seen that we've got a button has appeared and I can just do this interact One of the interesting things about this system and I've realized I've
definitely got more than 20 minute talk here is that we don't just treat all the parameters and fields in here as a property. One of the properties of every actor is its own code. So, we can send strings of code to an actor and it will in turn look up and bring in and compile and change its own behavior
and change its own configuration. So, I'm just going to add one more. So, three dimensional things flying around in here. So, what's different in the forest of actors approach as opposed to a standard actor system is each graph
here is actually single threaded and lock free. So, we can do real-time processing through chain of actors that are in other ways encapsulated but everything happens synchronously. But then we can have as many graphs as we want on as many machines as we want or locally. So, here possibly running if you're doing low latency stuff one particular graph in a separate VM to
control this garbage collection. Pass things around. So, here I've got a file listener. I'll come back to this this idea of ref in a minute but we've got a some code that's wrapping a watch service. And I can just find the file here and you'll see that it's appeared down here if I find that component. So,
you'll see the property is exposed. I'm doing that now if I find that code
itself and just open it in a standard text editor. So, we can immediately change things based on you know whatever we can have code actors that change other
actors and change them all running at runtime. Right, go back to the slides So, we have a forest of actors architecture. We have a pipeline of actors looks like this. These are all communicating within a single thread
context. But then we have multiple graphs that exist and in a way take the scheduling part of the actor model and do that and the encapsulation part down into the tree. Now, I have a range of other, so I didn't actually show you this, but in the hood there's seven or eight other actors that are part of the system. So, there's service registration. So, an actor receives some code and say
right I want something that will turn this into class so that you've got compiler background loading and then we can split that however we want. So, the actors receive their code as a string. Got code now what? So, what the key
things this is doing is splitting you know typical Java object is behavior state and identity in one thing and we split that into three. So, code component is the class that exists as the actor it's the identity last the entirety of the life of the actor itself. Code context is something that knows the
state of the code you had and the state of the code you want and knows how to transform one into the other. So, we're using basically a form of dependency injection to move state across and code delegate is something that then the user is writing their code and extending. There's a
little code connector which is used different which knows how to connect all the annotations together and build that recipe for you. So, a chain of messages started the actor says right I've got some new code I need the context for this code look at the contents right that may not have the byte code for that string already. So, that looks up a second service which is the compiler. The
reason for splitting those two things up is that instantiation is to happen on the same VM compilation doesn't so very often you can send it off. We so I wasn't extending a particular class here so all the strings you send are actually a class body so the the wrapping of that guess if it's like J
Shell does in terms of imports and certain configuration around it to compile it into a unit is done for you and all the way through this process nothing hits the file system so it's entirely in memory. So, we're not using
hot swap or J shell. Both useful tools in there yeah some really simple way of getting code into a Java application and that's just to use a class loader for every code iteration. So, one of the benefits of doing like this
is we can ensure that the user's code is replicable. So, it seems incremental you see the code flash as I change it you're you're developing something incremental in the ID but we're trying for something that's transactional it knows what you had where you're going so this idea remove code should never have happened it's no good just having history if you have a
REPL history you just run the entire thing to ensure you get to the same state potentially and you should for this idea so if we have a piece of code like this which is doing some filtering so I didn't get around to showing you but we take a input string and we map it to something else whatever and send it out we have this code suffix is property and then we
do this the only logical thing in an application for us to do that is that that connection does not exist and never did so we can't keep the previous connection in place we don't want suffix to change that's that's something we can it's a state we can keep so the environment tries very hard to look at
what is what needs to be reset and what doesn't to be logical and there's a lot of built-in support so rather than thinking about the hotswap side of things this is using an API to do the kind of transaction of change to make it
feel as natural as possible to use and then of course well you need to interact with other Java code eventually and some things maybe not map so yeah there's a ref type as a fallback so here you define basically how you initialize it so you supply say a constructor and so yeah there's quite
complex API that hooks into all these things if you need to define something custom but here just got lifts ref in it pass it an area less constructive next time that gets injected in that constructor will not be called but if you haven't defined an initialization and you try and apply to it to do
something with it it will still give you an error message so you at least have to explicitly tell it what you think it should do and also has this wonderful little bit of generics which yeah it's a little bit confusing but actually allows us to do a quite simple thing which is to actually add and remove listeners or tonight and then we have generic data types three minutes
I guess you're not going to hear me actually do some music on this one so we'll get back to that so we can pass generic data through a pipeline as well so this is a fairly recent addition and at the end of that data
we define a sink and we say what should happen when you create it when you need to create a new object when it needs to be cleared when it needs to accumulate so you've got two nodes going into one so you define that all at the sink
point and so you can then pass through arbitrary Java types all the way through the active graph in one through what's interesting about that then is that we can do functions as well so it's a way of sharing and even accumulating functions to apply to a big data set by literally drawing the lines from apply this about it and then this and run and it will just
accumulate that down so that was meant to be demo time too but I guess this talk is more than 20 minutes long so please do if you look on there are various videos around of me doing various versions of other things with it including the going into nightclubs and coding DSP lambdas to make break
but I want to do something there was a little bit more about what's going on under the hood so I hope you found that interesting the project practice live to org the there's a blog post that kind of covers some of this was just in time programming everything open source on github that's me if you're
interested in conversations further talking further I'd love to talk to you or grab a business card and email me or whatever thank you very much any questions so the question was do we have to use the GUI to control the
graph or to create graph no and one thing so one thing I realized I didn't
have time to show you was actually kind of terminal interaction to create so practice core and practice live practice live is the ID is based on the net beans ID practice cause completely separate application which is controlled in so different ways and yeah so the command line is one where you could build it up or you can absolutely send messages so all the add add this
component whatever build the graph connect is all done again by message passing to the actors so parent actors say add this type connect these is all done so you can control that through anything so there is a command line interface to do that but you can expose that in whatever way you want
so you mean so you could okay the question was can we translate back and
forth between CLI things and the GUI at the moment the way the ID is written it doesn't maintain a knowledge of things it hasn't created but that's definitely something that I'm currently working on there's no particular reason it has to do that though we can sync back and forth so
it will notice if you deleted an actor on the command line or something else deleted it it would disappear but if it if the ID hasn't created it it doesn't sink to it so it doesn't okay the question was what the
underlying communication mechanism so internally in a in a particular JVM you have multiple pipelines different threads that's a concurrent queue and whatever at the moment going between so there's any one class that handles all
the messages going through and out and at the moment I'm just using open sound control which is a very simple binary mechanism but nothing else in the environment needs to know yeah everything comes through basically a proxy actor in one system to a proxy actor on the other so to replace that
it's replaced one class so I have been looking at possibly something around Jiro MQ or and you know anything that can and it potentially there could be multiple implementations the same as the actor system it could be designed such that it can run on top of another existing distributed system so as
much as possible nothing in the graph knows how message it just says I'm sending a message you deal with it