grashalm

It's two jits in total.

This is the internet at its best.

That is a great strategy. It gets easier over time though. My tipp is to still join smoking friends, but just don't smoke. Makes you robust against the temptation longer term.

Any language can be sandboxed on the VM level. It's a property of it's implementation. So you can say that Lua has no sandbox friendly implementation right now.

For example, termination you can solve by unwinding the stack in efficiently polled safepoints. You need to take down the entire sandbox-capable Lua VM instance but you can.

Feel free to drop Dr. Futamura an email: https://fi.ftmr.info/

If he says yes to changing his name you have my full support.

I work on Truffle for more than 10 years and I recently wrote a comment on hackernews using Futurama instead of Futamura. That comment had it wrong twice.

Truffle has no opinion on how you parse the sources. It cares about how you execute them from an intermediate Truffle guided representation produced by the parser.

In other words antlr and truffle are a great fit. We even use this pairing for our example language simplelanguage.

https://github.com/graalvm/simplelanguage

Very few people have heard of them. That is exactly the reason why I mention them as often as I can. They are a great entry into the world of meta compilers.

He probably means one of the wonderfully crafted talks by Chris Seaton.

Here is one of the many: https://youtu.be/bf5pQVgux3c?si=S8Dm5d_GXYXgJtnY

If you go looking for more you will find many more marbles.

The truffle compiler extensions in Graal will be part of Galahad. For example the partial evaluator. The truffle framework and all the languages are consumed from a maven repo as a regular java library these days.

Some background on the recent changes there: https://medium.com/graalvm/truffle-unchained-13887b77b62c

Shameless self plug: Giving an introduction in this video: https://youtu.be/pksRrON5XfU?si=CmutoA5Fcwa287Yl

Damn you autocomplete! This happens all the time :D

Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources!

https://github.com/oracle/graal/tree/master/truffle

Disclaimer: graalvm dev here.

Edit: typo

Thanks for the link. I didn't know Peertube, yet.

I can't see how you can avoid the centralization problem and also have decent monetization for the videos. But I want to certainly become convinced that it can work. Crypto made me a decentralization skeptic.

Alternative to working with a big silicon valley giant. If you want to integrate/use YouTube you need to deal with whatever that company puts you up with. And as the article states, you don't want them to become grumpy at you; otherwise, they will turn you off even quicker. The only alternative I see is to develop a new YouTube, which seems unreasonable given how dominant Google is.

I don't understand what reasonable alternative there could be. Develop your own YouTube?

With the new GFTC license, we hope G1 is much more accessible now.

We do not do process isolation yet, although we have plans to implement that as well as a fallback strategy.

The advantage of the native-image-isolate-based isolation is that it is much more lightweight. For example, calls from and to the host application are much faster. There is no copying or expensive synchronization necessary. The disadvantage is that we need to do our own protections against attacks, as the OS protections between processes don't apply to such isolates. By default, we deploy software/compiler-based protections but are also very close to supporting hardware like Intel MPK.

If you have more questions, you can also drop by on Slack; we are a friendly bunch: https://www.graalvm.org/slack-invitation/

The Polyglot sandbox is licensed under GFTC: https://www.oracle.com/downloads/licenses/graal-free-license...

ISOLATED and UNTRUSTED require GFTC

CONSTRAINED is also available under open-source licenses.

Only for JavaScript right now. We are working hard on supporting all the other languages!

Developer here. So, if you have more questions, let me know!

I did some digging on past discussions, and yes, it seems the stars are not aligned for extension methods in standard Java.

But tbh, there are some very good arguments against extension methods. Also, some tricky questions about overloading handling and compatibility are lurking in the shadow. But if you have good suggestions on how to fix them, I'd take the time to propose something on an OpenJDK mailing list, maybe you get some support.

Well a language fork. But not a full implementation fork of course. Or would you argue that what Lombok does is part of the java spec? It effectively extends the java spec in non backwards compatible ways.

Another java fork like Lombok. But this time the authors didn't take the time to support all java compilers/IDEs, so the situation is even worse.

If this is just to highlight the merit of static extension methods with a follow up JEP I am all for it, but please don't advertise this as a feature for production. It's a trap.

Oh the wonderful luxury of writing code alone. I have not encountered this pleasure in commercial projects so far.

Nobody did that because java is a safe language by design. Manual allocation would make it an unsafe language. For the vast majority of applications correctness wins over performance.

Short lived objects are extremely cheap on the JVM with the right GC. Almost stack allocation cheap. So if you write code that avoids too many long lived objects there is almost no overhead to a GC.

For long lived objects GC based compaction can give you even some performance advantage over manual allocation due to better memory locality. But that heavily depends on the application of course.

In my experience people blame the GC way too early. Most often the application is just poorly written and some small tweaks can fix gc spikes.

Yes it seems like an exact match for Google's top box. But as mentioned, they need to work on explaining themselves. That is what the current top box still does better.

For ChatGPT to be the Google killer they need to provide source URLs.

Re JVM on wasm with gc: it might be simpler at first to build a Graal/native-image backend for wasm+gc. No runtime JIT needed. Happy to join in on the fun.

I'd ask people that know you and have experience in the field for a realistic opinion (maybe a professor/assistant/phd?). It does definitely not hurt to code all kinds of systems stuff. Try to tinker with some low-level optimization problems. You should be an excellent coder too. In our case it does help to know the JVM ecosystem, including HotSpot details.

And (shameless self plug), implement a Truffle language. Start here: https://www.youtube.com/watch?v=pksRrON5XfU&list=PLN193mR3Js...

I think with regular old java this would be impossible to do in a reasonable way. But with AOT compiled Java and extensions like @Uninterruptible you can do it.

I think I'd phrase it like this: you can write a GC mostly in Java.

Other GCs than the default Java one in native image like G1 actually embed the C++ version of the implementation instead of writing it in Java.

Graal dev here. We have an internship program: https://www.graalvm.org/community/internship/

It's not uncommon to do a CS master Thesis as part of an internship, if your university allows that. We have plenty of topics to choose from and you can also come up with your own.

Good luck!