Live data from Hacker News

RaptorJIT + Studio: Analyzing the evolving C heap of a JIT compiler (2017)

github.com

11–14 of 14 posts

Re: RaptorJIT + Studio: Analyzing the evolving C heap of a JIT compiler (2017)

#11
post #8

Earlier quoted context omitted.

>that it would be tragic if it just slowly fades into obsolescence. Not going to happen. Too many people have sworn to keep improving it.

For the LuaJIT family to die all that's necessary is for people to stop selecting it for new projects. Time takes care of the rest.

Sure. But when my fork with 10% more speed is released, some fairly large companies are going to choose it and it will continue.

Re: RaptorJIT + Studio: Analyzing the evolving C heap of a JIT compiler (2017)

#12
post #10
post #2

Author here with a little update from experience. Generally I am quite happy with this approach, but I am not wild about the cost/benefit of writing tools in Smalltalk. I've spent a lot of energy on treading water and trying to keep things working while the environment is being rewritten underneath my feet. I have also found that Smalltalk works best when data is imported into the Smalltalk heap, and represented by a…

In your opinion, should LuaJIT 2.1 users switch to RaptorJIT? I ask because the LuaJIT stewardship plan never materialized and it's been...too long.

Switching to RaptorJIT would get you a community that's more open to contribution, tracing and profiling with zero overhead that can be left enabled in production, and - on the downside - fewer supported platforms/architectures in the short term.

Re: RaptorJIT + Studio: Analyzing the evolving C heap of a JIT compiler (2017)

#13
post #8

Earlier quoted context omitted.

For the LuaJIT family to die all that's necessary is for people to stop selecting it for new projects. Time takes care of the rest.

Sure. But when my fork with 10% more speed is released, some fairly large companies are going to choose it and it will continue.

Sure. But if your plan is to do all the work by yourself, for the benefit of companies who aren't contributing much beyond occasional bug fixes, then you will eventually burn out like Mike Pall did. There won't necessarily be another sucker to take your place.

For the project to have a healthy future you really need a community of user-developers who are supported by multiple organizations and cooperating and coordinating with each other. LuaJIT doesn't currently have such a community and bootstrapping one is a doosey.

Re: RaptorJIT + Studio: Analyzing the evolving C heap of a JIT compiler (2017)

#14
post #13

Earlier quoted context omitted.

Sure. But when my fork with 10% more speed is released, some fairly large companies are going to choose it and it will continue.

Sure. But if your plan is to do all the work by yourself, for the benefit of companies who aren't contributing much beyond occasional bug fixes, then you will eventually burn out like Mike Pall did. There won't necessarily be another sucker to take your place. For the project to have a healthy future you really need a community of user-developers who are supported by multiple organizations and cooperating and coordin…

You're right and I think more than anything, it's a function of the license. New code needs to be LGPL.
Post reply on HN