El mi??, 21-09-2005 a las 08:29 -0700, will pugh escribi??:
I think having a FastJIT and forgoing the interpreter is a pretty
elegant solution, however, there are a few things that may come out
of this:
1) Implementing JVMTI will probabaly be more difficult than doing
a straight interpreter
2) The FastJIT needs to be Fast! Otherwise, you run the risk of
people not wanting to use it for IDEs and Apps because the startup
time is too slow.
I would have thought that implementing JVMTI for SlowJIT-ted code
would have been about as difficult as for the FastJIT-ted code ? Or
are we to assume that tools will only be used at the lowest level of
optimization ?
This is a good point. I might have been a bit overly broad. There are
a lot of peices of JVMTI, and not all of them are affected by the
compile vs. interpret decision, and then furthermore, given that you are
compiling the src, some of them are not affected by the no-optimization
vs. heavy optimization.
The cool thing about JVMTI is that it works by the agents asking for
capabilities that you can then use for determining in the VM what kinds
of optimizations to do.
I think that for a first release, getting the Debugging portions of
JVMTI working well (and hopefully early) are important. This is for a
few reasons:
1) Potential users are going to feel more comfortable working on a
rough VM that they can debug their problems on rather than one they can't
2) I suspsect we would get better bug reports out of it, because
users can look deeper into their bugs
3) I suspect that there are a few "special" objects we could add in
that could be accessed via a debugger to give more internal VM state
information to either Harmony Developers or Harmony Users. You could
imagine a HarmonyVM object that can dump or report vm state that is
useful in debugging VM problems.
HarmonyVm.showReferencesToObject(fooObject)
That being said, I've grouped the JVMTI capabilities into groups of
which I think are orthagonal to the issue, ones that would be
significantly easier on an interpreter vs. compiled code, and then
further into what I think would be more difficult in optimized code vs.
non-optimized.
This is a sort of "off the top of my head" analysis. Some things are in
both lists because they are easier to do in a compiled world than an
uncompiled world, but can also get really hard when trying to do them in
a highly-optimized world. If I have more time, today, I can try writing
up notes for how I think each of these would be implemented and folks
can tell me if they think I'm making some of them harder than need be.
EASIER IN INTERPRETER THAN COMPILED:
can_generate_field_modification_events
can_generate_field_access_events
can_pop_frame
can_signal_thread
can_generate_single_step_events
can_generate_exception_events
can_redefine_any_class
can_generate_breakpoint_events
EASIER IN NON_OPTIMIZED CODE THAN OPTIMIZED:
can_generate_field_modification_events
can_generate_field_access_events
can_access_local_variables
can_pop_frame
can_redefine_classes
can_get_line_numbers
can_access_local_variables
can_generate_frame_pop_events
can_generate_method_entry_events
can_generate_method_exit_events
can_generate_breakpoint_events
ORTHAGONAL
can_tag_objects
can_get_bytecodes
can_get_synthetic_attribute
can_get_owned_monitor_info
can_get_current_contended_monitor
can_get_monitor_info
can_get_source_file_name
can_signal_thread
can_get_source_debug_extension
can_maintain_original_method_order
can_suspend
can_get_current_thread_cpu_time
can_get_thread_cpu_time
can_generate_all_class_hook_events
can_generate_compiled_method_load_events
can_generate_monitor_events
can_generate_vm_object_alloc_events
can_generate_native_method_bind_events
can_generate_garbage_collection_events
can_generate_object_free_events
