Ticket #448 (closed deprecation: fixed)

Opened 5 years ago

Last modified 4 years ago

[TODO] Migrate non-essential PMCs to dynpmcs

Reported by: allison Owned by: coke
Priority: normal Milestone: 2.4
Component: none Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

Several PMCs that are currently compiled as core could (and likely should) be dynamic PMCs instead. Candidates include: AddrRegistry, CodeString, Env, Eval, File, OS, PCCMETHOD_Test, StringHandle, and Timer.

Change History

  Changed 5 years ago by pmichaud

The CodeString PMC is used extensively by PGE and PCT to generate PIR output. There wouldn't seem to be much advantage to making it into a dynpmc.

Similarly, Eval PMCs are the result of compiling PIR to bytecode, so I suspect those should stick around as well.

Lastly, I would think that almost every language will end up using the Env PMC in order to access environment variables. It also wouldn't surprise me if PCT::HLLCompiler ends up probing the environment in places.

Pm

  Changed 5 years ago by coke

  • owner set to coke

  Changed 5 years ago by coke

  • status changed from new to assigned

Allison, do you have any input on Patrick's objections here?

follow-up: ↓ 5   Changed 5 years ago by allison

Go ahead and move Env to dynpmc (it's used, but not frequently, and the dynpmcs are still core).

There's not really any advantage to having CodeString as a core PMC. Would make more sense as a PIR class (PCT::CodeString or something like that).

Keep Eval for now (ignore it when closing the ticket), but the result of compiling a string should be a Sub object or a Packfile object, not an Eval. I've opened a separate ticket (TT #905) about deprecating Eval, as it should be removed entirely, not moved to a dynpmc.

in reply to: ↑ 4 ; follow-up: ↓ 12   Changed 5 years ago by pmichaud

There's not really any advantage to having CodeString as a core PMC. Would make more sense as a PIR class (PCT::CodeString or something like that).

Originally CodeString was a PIR class. We moved it to being a core PMC because it's primary method (emit) is significantly faster written in C than in PIR, and this directly affects compilation speed.

I'd prefer to see that remain the case. Or if we would be better served by creating an 'emit' opcode (that could do the work in C), I'd be okay with that.

If Parrot supports a StringBuffer type that would work as a replacement, we might be able to use that.

Pm

  Changed 5 years ago by coke

  • status changed from assigned to new
  • owner coke deleted

  Changed 5 years ago by chromatic

  • milestone changed from 2.0 to 2.1

  Changed 4 years ago by coke

  • type changed from todo to deprecated

  Changed 4 years ago by allison

  • milestone changed from 2.2 to 2.6

  Changed 4 years ago by allison

  • milestone changed from 2.6 to 2.3

  Changed 4 years ago by gerd

  • milestone changed from 2.3 to 2.4

in reply to: ↑ 5   Changed 4 years ago by coke

Replying to pmichaud:

There's not really any advantage to having CodeString as a core PMC. Would make more sense as a PIR class (PCT::CodeString or something like that).

Originally CodeString was a PIR class. We moved it to being a core PMC because it's primary method (emit) is significantly faster written in C than in PIR, and this directly affects compilation speed. I'd prefer to see that remain the case. Or if we would be better served by creating an 'emit' opcode (that could do the work in C), I'd be okay with that. If Parrot supports a StringBuffer type that would work as a replacement, we might be able to use that. Pm

FYI, The CodeString in branches/codestring now basically uses a StringBuffer under the covers; .emit() adds chunks (doing the substitution), while the get_string VTABLE collapses it into a String.

  Changed 4 years ago by coke

The original list was AddrRegistry, CodeString, Env, Eval, File, OS, PCCMETHOD_Test, StringHandle, and Timer.

PCCMETHOD_Test is already moved.

CodeString & Env were both questioned as to whether or not they should be moved.

Eval is now referenced in other tickets.

That leaves the following as safe to move.

AddrRegistry
File
OS,
StringHandle
Timer

  Changed 4 years ago by chromatic

On Monday 03 May 2010 at 12:38, Parrot  wrote:

>  That leaves the following as safe to move.
> 
>  {{{
>  AddrRegistry
>  File
>  OS,
>  StringHandle
>  Timer
>  }}}

AddrRegistry is *not* safe to remove.  It's part of the root set.  Please 
remove it from the list.

-- c

follow-up: ↓ 17   Changed 4 years ago by coke

Note that Timer is used by src/scheduler.c and the Scheduler PMC; StringHandle is used by src/io/api.c.

That leaves only File and OS.

  Changed 4 years ago by coke

  • owner set to coke

in reply to: ↑ 15   Changed 4 years ago by coke

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

Replying to coke:

Note that Timer is used by src/scheduler.c and the Scheduler PMC; StringHandle is used by src/io/api.c. That leaves only File and OS.

Which were converted in r46259. Resolving ticket.

If you feel strongly that any of the other items on here should be Dynamic PMCs, you have until 2.6.0's release to re-open this ticket and re-add the deprecation notice. This only covers items in the original list. After that release, a new ticket will be needed.

Note: See TracTickets for help on using tickets.