Monkey's paw: you get your wish, but so does someone who wants RAII and single-use-malloc to be left behind as a leaky and bad abstractions.
We all happily march into a future where only arena allocation is allowed, and when the arena is overfull it can only be fully reset without saving data. Copying still-used data out if it before reset is not allowed, as that's a copying half-space garbage collector. Reference counting is of course not allowed either as that's also garbage collection. Everyone is blessed...?
Author here: to get the compiler to help me as the programmer to produce correct code (not accidentally using handles after GC) without being massively manual, but (at least currently) accepting that it is not a guarantee and thus runtime checks (bounds checks in my case) are needed to retain memory safety.
I'm a little sad to see YJIT go down in favour of a traditional design. (Yes, YJIT isn't "deprecated" but the people working on it are now mainly working on something else. That's hardly a great place to be in.)
I'm personally quite interested in trying out an LBBV JIT for JavaScript, following in Chevalier-Boisvert's Higgs engine's footsteps. The note about a traditional method JIT giving more code for the compiler to work with does ring very true, but I'd just like to see more variety in the compiler and JIT world.
Like: perhaps it would be possible to conjoin (say) an LBBV with a SoN compiler such that LBBV takes care of the quick, basic compilation and leaves behind enough data such that a SoN compiler can be put to use on the whole-method result once the whole method has been deemed hot enough? This is perhaps a totally ridiculous idea, but it's the kind of idea that will never get explored in a world with only traditional method JITs.
Tier-ups for trace-based JITs have been explored before. You can find an example here https://dl.acm.org/doi/abs/10.1145/2398857.2384630 I know LBBV isn't technically tracing, but it's quite similar, so I think similar concepts apply.
Preface: I am not a compiler engineer at all, so I'm just spitballing silliness here.
Avoidance of type feedback counters and such. Get LBBV to clean out the redundant type checks (Higgs proved this well, avoiding something like >90% of them) and produce a format, perhaps a high-level bytecode or just an HIR, that can be used as an input to start a method-level JIT compilation.
So, LBBV gives the quick and easy basic block compilation and cleans up the very easy stuff but leaves enough information so that a follow-up compiler can still use it as input.
As a fellow (but way junior) JavaScript engine developer I'm really happy to see the stricter mode, and especially Arrays being dense while Objects don't treat indexed properties specially at all: it is my opinion that this is where we should drive JavaScript towards, slow and careful though it may be.
In my engine Arrays are always dense from a memory perspective and Objects don't special case indexes, so we're on the same page in that sense. I haven't gotten around to creating the "no holes" version of Array semantics yet, and now that we have an existing version of it I believe I'll fully copy out Bellard's semantics: I personally mildly disagree with throwing errors on over-indexing since it doesn't align with TypedArrays, but I'd rather copy an existing semantic than make a nearly identical but slightly different semantic of my own.
Guidance towards correct usage: eg. If you allow `a[10] = 2` and just make the Array dense, the user might not even realise the difference and will assume it's sparse. Next they perform `a[2636173747] = 3` and clog up the entire VM memory or just plain crash it from OOM. Since it's likely that the small indexes appear in testing and the large indexes appear in production, it is better to make the misunderstanding an explicit error and move it "leftwards" in time, so that it doesn't crash production at an inopportune moment.
Hmm, I at least received a refund on the tablet; I think half of it was paid out and half of it I opted to use as payment for Sailfish X.
An email I have stored from July 4th 2017 mentions "the tablet refund tool", so there seems to have been a concrete system for this refunding process as well. I abstractly remember something like that, though I must say my memory is shoddy and should not be trusted.
This is the last response I have from them in my inbox (Sep 24, 2015, 8:56 AM). Never heard back from them after this inspite of repeated subsequent queries
----------------
Hi,
thank you for your message.
We are sending the invites out to contributors in groups according to the chronological order of contributions. Please also note that we are slowly ramping up the deliveries, starting with a smaller group to ensure that everything works as it should, but anticipate future groups to be bigger in size. This means that we are currently unable to estimate your exact order number in the queue.
To read all the latest on the Tablet campaign, please stay tuned to the Jolla Blog. For some commonly asked questions and answers, please see our Jolla Tablet Campaign FAQs.
Thank you again for your contribution!
Sincerely,
Jolla Customer Care
Operating hours: Monday to Friday from 9.00 - 17.00 GMT +2; close weekends and public holidays (Finland).
Join the Movement @ jolla.com
Like us on Facebook @ jollaofficial
Follow on Twitter @ jollaHQ
Dive deeper into the Jolla world @ Official Jolla Blog
I low-key hate myself for this, but I went and preorder. I've been waiting for SFOS to come to my Xperia 10 IV but that seems to still be in beta, and after quite a few years it'd be hard to switch over ask well... But I have to try support Jolla as they've been my go-to phone OS maker for the last 10-15 years.
We all happily march into a future where only arena allocation is allowed, and when the arena is overfull it can only be fully reset without saving data. Copying still-used data out if it before reset is not allowed, as that's a copying half-space garbage collector. Reference counting is of course not allowed either as that's also garbage collection. Everyone is blessed...?
reply