harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From will pugh <willp...@sourcelabs.com>
Subject Re: [arch] Interpreter vs. JIT for Harmony VM
Date Thu, 22 Sep 2005 16:48:47 GMT

>>> 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





Mime
View raw message