Ok, so I think we should defer on the object allocation ones for now
and focus on a few that are coarse-grained and general purpose.
Thoughts below.
On Tue, Jul 16, 2013 at 2:25 AM, Chamila Wijayarathna
<cdwijayarat...@gmail.com> wrote:
> · 1. Object-create -: fired when an object is about to allocated
>
> · 2. Array-create -: fired when an Array is about to be allocated
>
> · 3. Hash-create -: fired when an Hash is about to allocated
>
> · 4. String-create -: fired when String is about to allocated
>
> · 5. Symbol-create -: fired when symbol is about to be allocated
Skip these for now. We need to figure out where and how to hook into
allocation/construction to have low impact but high accuracy.
Something to look into would be whether the built-in JVM/Hotspot
dtrace allocation probes could be leveraged. For example... instead of
adding our own String-create probe, could we just say to use the
Hotspot "Allocate-object:org.jruby.RubyString" probe or something? Or
can we alias that probe to a new short name?
> · 6. Parse-begin -: fired just before parsing and compiling a source
> file
>
> · 7. Parse-end –: fired just after parsing and compiling a source
> file
These would be easy and useful to add now.
> · 8. method-entry -: Fired just before a method is entered.
>
> · 9. method-return -: Fired just after a method has returned.
Skip for now; need to figure out the right way to do this. We have a
lot of ways methods get called and don't want to have to modify every
place.
> · 10. Load-entry -: fired when calls to “load” are made
>
> · 11. Load-return -: fired when load returns.
>
> · 12. Raise –: fired when an exception is raised
All good. Raise will not catch everything because exception raises
from Java code don't go through Kernel.raise, but if you added a probe
to Kernel.raise for now it would be a good start.
> · 13. Java-method-entry -: fired just before a Java method is
> entered
>
> · 14. Java-method-return -: fired just before Java method is
> returned
These are possible, and maybe even can be made very cheap, but they'll
require some deeper code-generation work. I'll work directly with you
when we get to this point.
It's again possible (actually, likely) that the existing Hotspot
dtrace support already has method invocation probes we could
piggy-back on.
>
> · 15. Require-entry -: fired on calls to rb_require_safe
>
> · 16. Require-return -: fired just before rb_require_safe returns
>
> · 17. Find-require-entry -: fired just before search_required is
> called
>
> · 18. Find-require-return -: fired just after search_required
> returns
Good.
> · 19. Gc-mark-begin -: fired at beginning of mark phase
>
> · 20. Gc-mark-end -: fired at the end of mark phase
>
> · 21. Gc-sweep-begin -: fired at the beginning of a sweep phase
>
> · 22. Gc-sweep-end -: fired at end of sweep phase.
These don't mean anything for us, and a dtrace-enabled JVM will again
already have its own GC probes.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
