On Jul 11, 2012, at 2:35 PM, Vladimir Kozlov wrote:

> c1_GraphBuilder.cpp, can you remove setting bailout message for forced 
> inlining? It should be done proper uniform way for C1 inlining later.

In the final version (a couple patches later) it looks like this:

  // now perform tests that are based on flag settings
  if (callee->force_inline() || callee->should_inline()) {
    // ignore heuristic controls on inlining
    print_inlining(callee, "force inline by annotation");

-- Chris

> 
> I think, next assert should check (id >= _unknown && id < _annotation_LIMIT) 
> instead:
> 
> +    void set_annotation(ID id) {
> +      assert((int)id > 0 && (int)id < BitsPerInt, "oob");
> 
> 
> In header file classFileParser.hpp you should not specify ClassFileParser:: 
> in method parse_classfile_attributes(() declaration:
> 
> ClassFileParser::ClassAnnotationCollector* parsed_annotations
> 
> 
> Instead of asserts in apply_to() methods we should use guarantee("not 
> implemented") or something.
> 
> 
> I don't think next should be part of these changes:
> 
> +#if 0
> +    // The parsing of @Retention is for example only.
> 
> 
> Add parenthesis around expression in next condition:
> 
> +  while (--nann >= 0 && index-2 + min_size <= limit) {
> 
> 
> Instead of passing pointers to classFileParser's new attributes fields 
> (_synthetic_flag, _sourcefile, ...) as arguments add accessors functions 
> which set these fields.
> 
> 
> I think next is typo, should be _in_method check:
> 
> +  case 
> vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature):
> +    if (_location != _in_class)  break;
> +    return _method_ForceInline;
> +  default: break;
> +  }
> 
> Thanks,
> Vladimir
> 
> John Rose wrote:
>> This is a building block for an upcoming large enhancement for method 
>> handles.
>> http://cr.openjdk.java.net/~jrose/6711908/webrev.00
>> The implemented interface is completely private to the java.lang.invoke 
>> package.
>> — John

_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to