Project

General

Profile

Actions

Feature #13133

closed

TracePoint: Add event type for constant access

Added by burke (Burke Libbey) almost 8 years ago. Updated over 7 years ago.

Status:
Rejected
Target version:
-
[ruby-core:79102]

Description

Hi there,

I've attached a patch to add a new :constant_access TracePoint event.

One feature and/or bug, depending on your perspective: since this event fires from setinlinecache, the event is only triggered:

  • after nested constant resolution: for A::B, only one event is triggered (because getinlinecache/getconstant/getconstant/setinlinecache);
  • on cache miss: it cannot be used for things like counting iterations, which limits possible uses, but reduces overhead (because getinlinecache jumps over setinlinecache on a hit).

The use-case I have in mind here is to enable building runtime package/component boundary enforcement systems. For this case, both of the above properties are ideal.

Enforcing package boundaries is a problem we've been discussing a lot lately at Shopify.

If you want a more concrete usage example for this patch, I have some proof-of-concept code posted that makes use of it to construct a fairly minimal package system. Packages::CONSTANT_ACCESS_TRACEPOINT is the particularly relevant bit.


Files

Updated by shyouhei (Shyouhei Urabe) almost 8 years ago

  • Status changed from Open to Assigned
  • Assignee set to ko1 (Koichi Sasada)

Updated by ko1 (Koichi Sasada) over 7 years ago

Enforcing package boundaries is a problem we've been discussing a lot lately at Shopify.

I understand the issue. But your patch and your design needs more consideration.

  • Your patch provide a hook only on const cache miss, but the name constant_access I assume it hooks all of constant accesses.
  • Your patch inserts the hook only in insns.def, but C level constant access is available.
  • Not only constant access, constant setting or reopen class/modules are also needed to analyze (and introduce restriction if needed into ) program behavior.

Updated by burke (Burke Libbey) over 7 years ago

All good points, thank you. I definitely agree that the implementation is not good. Feel free to close this. I'll see if I can find a better way to accomplish my goals here some other time.

Actions #4

Updated by ko1 (Koichi Sasada) over 7 years ago

  • Status changed from Assigned to Rejected
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0