| 344 |
|
* The table is resized when occupancy exceeds a percentage |
| 345 |
|
* threshold (nominally, 0.75, but see below). Any thread |
| 346 |
|
* noticing an overfull bin may assist in resizing after the |
| 347 |
< |
* initiating thread allocates and sets up the replacement |
| 348 |
< |
* array. However, rather than stalling, these other threads may |
| 349 |
< |
* proceed with insertions etc. The use of TreeBins shields us |
| 350 |
< |
* from the worst case effects of overfilling while resizes are in |
| 347 |
> |
* initiating thread allocates and sets up the replacement array. |
| 348 |
> |
* However, rather than stalling, these other threads may proceed |
| 349 |
> |
* with insertions etc. The use of TreeBins shields us from the |
| 350 |
> |
* worst case effects of overfilling while resizes are in |
| 351 |
|
* progress. Resizing proceeds by transferring bins, one by one, |
| 352 |
|
* from the table to the next table. However, threads claim small |
| 353 |
|
* blocks of indices to transfer (via field transferIndex) before |
| 380 |
|
* a forwarding node during a traversal, to maintain its place if |
| 381 |
|
* later processing the current table. The need for these |
| 382 |
|
* save/restore mechanics is relatively rare, but when one |
| 383 |
< |
* forwwarding node is encountered, typically many more will be. |
| 383 |
> |
* forwarding node is encountered, typically many more will be. |
| 384 |
|
* So Traversers use a simple caching scheme to avoid creating so |
| 385 |
|
* many new TableStack nodes. (Thanks to Peter Levart for |
| 386 |
|
* suggesting use of a stack here.) |
