RFR(xs): 8134744: WorkerThread::id() should match GangWorker's worker_id
derek.white at oracle.com
Mon Aug 31 22:12:50 UTC 2015
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
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.
On 8/31/15 2:35 PM, Jon Masamitsu wrote:
> 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"?
> On 08/31/2015 07:16 AM, Per Liden wrote:
>> 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
More information about the hotspot-gc-dev