RFR: 8031639: make dependency management (mostly) ci independent

Doug Simon doug.simon at oracle.com
Tue Jan 14 05:14:17 PST 2014


On Jan 14, 2014, at 7:42 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> I like the change.  What was the motivation for choosing:
> 
> positive: metadata, negative: object

To avoid collisions since the id is based on indexes in separate data structures (OopRecorder::_metadata and OopRecorder::_oops). This choice of which is negative and positive is arbitrary.

> If it would be the other way around you wouldn't have to negate the sort key:
> 
> +    // Used to sort values in ascending order of index() with metadata values preceding object values
> +    int sort_key() const { return -_id; }

I don’t think it matters that metadata sort before object values, just as long as they are distinguished from each. That is, the comment is describing what sort order is produced as opposed to being a requirement on the sort order.

> 
> src/share/vm/code/dependencies.hpp:
> 
> +  bool note_dep_seen(int dept, DepValue x) {
> +    assert(dept < BitsPerInt, "oops");
> +    // place metadata deps at even indexes, object deps at odd indexes
> +    int x_id = x.is_metadata() ? x.index() * 2 : (x.index() * 2) + 1;
> 
> This means we’re using twice as much memory for seen dependencies but I guess it doesn’t matter much.

I don’t think it matters.

> On a related note to the comment above if _id would be:
> 
> +        _id = (rec->find_index(metadata) << 1) | 1;
> 
> we would have unique, ready-to-use indexes.

If this is applied to DepValues for oops as well, then yes, almost. We’d still need the negation for objects and DepValue::index() would have to do the reverse shift. Not sure if makes any real difference.

>  Is there a reason why metadata and object values need to be grouped together?

Grouped together where?

-Doug

> On Jan 13, 2014, at 2:55 PM, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> Hi all,
>> 
>> I would like to request a review for a change to the Dependencies class such that it can be used to register assumptions based on either ci* values or raw values. The motivation is support compilers (such as Graal) that don't use the ci interface. 
>> 
>> jbs:    https://bugs.openjdk.java.net/browse/JDK-8031639
>> webrev: http://cr.openjdk.java.net/~dnsimon/JDK-8031639/
>> 
>> -Doug
>> 
> 



More information about the hotspot-compiler-dev mailing list