Just-in-Time Programming
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| 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 | 10.5446/47231 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2020374 / 490
4
7
9
10
14
15
16
25
26
29
31
33
34
35
37
40
41
42
43
45
46
47
50
51
52
53
54
58
60
64
65
66
67
70
71
72
74
75
76
77
78
82
83
84
86
89
90
93
94
95
96
98
100
101
105
106
109
110
116
118
123
124
130
135
137
141
142
144
146
151
154
157
159
164
166
167
169
172
174
178
182
184
185
186
187
189
190
191
192
193
194
195
200
202
203
204
205
206
207
208
211
212
214
218
222
225
228
230
232
233
235
236
240
242
244
249
250
251
253
254
258
261
262
266
267
268
271
273
274
275
278
280
281
282
283
284
285
286
288
289
290
291
293
295
296
297
298
301
302
303
305
306
307
310
311
315
317
318
319
328
333
350
353
354
356
359
360
361
370
372
373
374
375
379
380
381
383
385
386
387
388
391
393
394
395
397
398
399
401
409
410
411
414
420
421
422
423
424
425
427
429
430
434
438
439
444
449
450
454
457
458
459
460
461
464
465
466
468
469
470
471
472
480
484
486
487
489
490
00:00
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
05:21
Computer programSystem programmingRange (statistics)Connectivity (graph theory)Computer animationLecture/Conference
05:58
System programmingCore dump
06:17
Right angleGroup actionSystem programmingCategory of beingRange (statistics)Zoom lensType theoryMessage passingCodeProcess (computing)Graphics libraryFunctional programmingSource code
07:43
Type theorySystem programmingVirtual machineSystem callEntire functionIntegrated development environmentGroup actionRun time (program lifecycle phase)SoftwareFlow separationConnected spaceMathematicsSource code
08:45
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
10:47
Slide ruleCodeRun time (program lifecycle phase)Computer animation
11:06
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
16:25
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
21:39
Open sourcePoint cloudFacebookComputer animationLecture/Conference
Transcript: English(auto-generated)
00:13
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
00:25
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
00:48
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
01:07
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.
01:23
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
01:40
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
02:05
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
02:24
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
02:41
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,
03:03
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
03:20
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
03:43
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
04:06
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
04:21
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
04:42
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
05:03
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
05:22
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
05:42
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
06:02
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
06:26
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,
06:48
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
07:04
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
07:24
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
07:43
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
08:03
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
08:26
blip. We'll make a little action and we'll take size and we'll do zero. Okay. So, I've added a
08:46
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
09:02
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
09:22
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
09:40
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
10:02
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,
10:38
you'll see the property is exposed. I'm doing that now if I find that code
10:43
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
11:01
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
11:22
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
11:44
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
12:01
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
12:22
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
12:40
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
13:04
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
13:23
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
13:40
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
14:00
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
14:23
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
14:45
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
15:04
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
15:20
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
15:44
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
16:00
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
16:26
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
16:44
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
17:00
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
17:22
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
17:43
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
18:03
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
18:34
graph or to create graph no and one thing so one thing I realized I didn't
18:40
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
19:02
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
19:38
so you mean so you could okay the question was can we translate back and
19:43
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
20:03
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
20:25
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
20:42
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
21:02
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
21:22
much as possible nothing in the graph knows how message it just says I'm sending a message you deal with it