While it doesn't make sense to use more than one core for the Eclipse product given the compiler is single core, it's likely you will want to use multiple cores in a production environment possible spread over several servers.
By default the license server will grant a license for the maximum number of cores your license is enabled for, to the first client that requests a license.
However you may wish to 'reserve' cores so that you can split work across multiple servers (vm's or physical).
In order to do this you can add an additional line to the license file before requesting a license, or, once you have a license, add the line, and force a new license check using the HCILicensing.jar file. This technical can be used to raise or lower the cores in use on a machine.
In order to request a specific number of cores you add the line
<product>.request_cores=<number of cores>
To your license file.
The license server will check if you have enough cores left in the total cores for your license (based on how many cores already in use for that product) and respond accordingly. By default, if you do not have enough cores the license check with fail and the product will not function.
You may also tell the license server to allow as many cores as are available up to the amount you requested. to do this, add the line
To your license file.
To understand this in practice consider the following scenario and settings:
You have 4 cores granted to your license.
Machine A requests 2 cores , flexible_cores=no -> License server returns 'OK' and grants 2 cores.
Machine B requests 2 cores , flexible_cores=no -> License server returns 'OK' and grants 2 cores.
Machine A now requests 3 cores , flexible_cores=no -> License server returns 'NO' and fails to grant a license.
Machine A now requests 3 cores , flexible_cores=yes -> License server returns 'OK' and grants 2 cores.
Machine B stops requesting cores and the lack of usage causes those 2 cores to be return to your 'pool'.
Machine A now requests 3 cores , flexible_cores=no -> License server returns 'OK' and grants 3 cores.
From the examples above you can see how cores can be spread between servers in order to split production workload, balancing cores as required.
As servers stop using cores (they no longer request periodic license updates ) those cores are returned to the pool for use by other instances of the product.