The basic logic here works this way:
1. attach a debugger to the current process
2. register a method entry request with the debugger for a prepared "hook class"
3. iterate over all object references as those method entry events
fire, replacing references on the stack
It's a hack, no doubt about it, but it's a cute hack. I'm essentially
co-opting JDI to implement a runtime feature (live heap-walking) that
normally would require JVMTI or equivalent native code.
Comments, questions, hate mail welcome.
- Charlie
Wouldn't maintaining a weak set initialized by the constructor be preferable?
--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures
That's what we do now, but I'd like to just rip that code completely
out so we don't have to check a flag "should I add myself or not". And
the weakref method means you have n * <ruby object count> extra
objects in memory, along with the tremendous perf hit of constructing
a weakref for every ruby object construction.
In the end, this is too slow, so it's only an interesting JDI hack.
But it's cute :)
I may look into a JVMTI version instead, since it would be a lot
closer to the metal and we may be able to bind the JNI methods
dynamically using JRuby's FFI layer.
- Charlie
> That's what we do now, but I'd like to just rip that code completely
> out so we don't have to check a flag "should I add myself or not".
The WeakSet should do that for you, no? That's the point of sets.
Set<E> weakSet = Collections.newSetFromMap(WeakHashMap<E, Boolean>();
> And
> the weakref method means you have n * <ruby object count> extra
> objects in memory, along with the tremendous perf hit of constructing
> a weakref for every ruby object construction.
That is annoying. Unfortunately, Reference is magic: you cannot give
ordinary classes the ref nature.
>
> In the end, this is too slow, so it's only an interesting JDI hack.
> But it's cute :)
>
> I may look into a JVMTI version instead, since it would be a lot
> closer to the metal and we may be able to bind the JNI methods
> dynamically using JRuby's FFI layer.
>
> - Charlie
>
> --
>
> You received this message because you are subscribed to the Google Groups "JVM Languages" group.
> To post to this group, send email to jvm-la...@googlegroups.com.
> To unsubscribe from this group, send email to jvm-language...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
That's not quite what I meant...I meant we already have logic in JRuby
to avoid adding transient object constructions to ObjectSpace, so all
other constructions have to check a flag to know they should add
themselves. If we could rely entirely on JDI (or similar) for
ObjectSpace, we would just remove that flag check entirely.
- Charlie
> That's not quite what I meant...I meant we already have logic in JRuby
> to avoid adding transient object constructions to ObjectSpace, so all
> other constructions have to check a flag to know they should add
> themselves. If we could rely entirely on JDI (or similar) for
> ObjectSpace, we would just remove that flag check entirely.
I see. Unfortunately, nobody ever bothers to optimize debugging
interfaces, even though they offer marvelous reflection (example:
ptrace)