Ticket #1020 (closed RFC: fixed)

Opened 5 years ago

Last modified 4 years ago

subclassing pmc from pir + lot more

Reported by: jessevdam Owned by:
Priority: normal Milestone:
Component: core Version: 1.6.0
Severity: medium Keywords: subclass typeof
Cc: Language:
Patch status: Platform: all

Description

See attach for the description.

Attachments

plan.txt Download (11.1 KB) - added by jessevdam 5 years ago.
the describtion
plandoc.txt Download (11.6 KB) - added by jessevdam 5 years ago.
update and added documentation on the change

Change History

Changed 5 years ago by jessevdam

the describtion

Changed 5 years ago by whiteknight

  • type changed from bug to RFC

It's a very interesting plan, very ambitious though. While the details are certainly going to need careful review, I think the gist of this plan is something that we really should consider in the long run.

We don't want to recurse runloops for every single VTABLE call on every single PMC like we have to do now with Object.pmc. The only way to get this working is to implemented Lorito and use Lorito to implement large amounts of Parrot (ops, several support routines, etc). Once we have that, we would need to declare that VTABLEs can only be called through Lorito, never from C. This is going to require a major refactor of our current API across the board.

This is also not to mention that there is currently going to be a speed penalty when things are implemented in PIR/Lorito instead of in pure C. I have high hopes that converting everything to Lorito (to avoid messy context switches) and optimizing heavily will actually make a Lorito-based solution faster in the long run. But until we reach that "long run" point, things would slow down significantly.

Changed 5 years ago by cotto

Your plan sounds interesting but your proposal is hard to read and understand. Please try to use as few words as possible to describe what you want to do. It'd also help if your proposal had some more structure. For something this big I recommend a wiki page.

Also, make sure to state what this will win us and how. Like whiteknight mentioned, this sounds like a huge amount of work that could also make Parrot much slower at a time when we're aggressively profiling and optimizing.

That said, Lorito is on the horizon and your proposal might start to look more feasible as Lorito takes shape. I'd encourage you not to develop code that can't be applied as a series of separate (ideally small and self-contained) patches, but please do continue to participate in the discussion.

Changed 5 years ago by jessevdam

update and added documentation on the change

Changed 5 years ago by jimmy

Changed 4 years ago by cotto

  • status changed from new to closed
  • resolution set to fixed

I've gone through the suggestions and evaluated them as best I could. Most of them are rejected, but that's only because we're going to be reimplementing PMCs in terms of 6model. The ideas aren't too bad, but 6model is more comprehensive and better-designed, in addition to being what nqp will be built on.

Additionally, please don't dump a huge ball of changes here like this. Free-form brain dumps are ok as a starting point, but when you're proposing changes the onus is on you to make them easily understandable. At any rate, please do get to know 6model and participate in development as we work on implementing it and integrating it into Parrot.

Note: See TracTickets for help on using tickets.