RFR(xs): 8134744: WorkerThread::id() should match GangWorker's worker_id

[Derek White]

Hi Per,

I'm confused on the same issue, or I've gotten lost between thinking 
about [Abstract] (WorkGang | GangWorker) :-)

AbstractWorkGang::initialize_workers() assigns ids from 
0..total_workers(). This id is also GangWorker's index into the 
AbstractWorkGang's_worker array. So changing GangWorker's id breaks 
implied consistency that AbstractWorkGang::worker(some_gang_worker._id) 
== some_gang_worker. Right? This seem more confusing than the WorkData's 
_worker_id != GangerWorkers._id.

Note that I didn't see how WorkerThread::id(), mentioned below, fits in 
this picture.

Since the WorkData's _worker_id is arbitrarily handed out, but the 
GangWorker's id is an index into an array, it seems safer to keep 
GangWorker's ID static, and setting WorkData's id when it gets assigned 
to a worker.

  - Derek

On 8/31/15 2:35 PM, Jon Masamitsu wrote:
> Per,
>
> A GangWorker is given an "uint id" when it is
> created.  If it is going to be reset the id whenever it
> does work, should it have its own "id"?
>
> Jon
>
> On 08/31/2015 07:16 AM, Per Liden wrote:
>> Hi,
>>
>> This is a follow up patch to JDK-8134749 (SoftReferences declared 
>> dead too early), which makes sure WorkerThread::id() and match 
>> GangWorker's worker_id always match. This allows them to be used 
>> interchangeably, which is both convenient and removes a potential 
>> source for bugs (it's easy to assumed they are the same). This change 
>> should not affect any existing code.
>>
>> Webrev: http://cr.openjdk.java.net/~pliden/8134744/webrev.0/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134744
>>
>> Testing: jprt
>>
>> /Per
>>
>