ICU-22582 Avoid synchronizing in RuleBasedBreakIterator and ULocale unless strictly necessary

[Diego1149]

https://unicode-org.atlassian.net/browse/ICU-22582

Optimize synchronized code which is causing contention which leads to latency degradation.

RuleBasedBreakIterator: Remove fBreakEngines and instead read from the static gAllBreakEngines, this of course has issues, which we fix by using a ConcurrentLinkedQueue and read as normal, but write within a synchronized context, we will only iterate over the LanguageBreakEngines we haven't iterated over and then add a new one if needed.

ULocale: If the Locale hasn't changed then use the cached value, else go through the code path that modifies it. (Similar solution to what Locale is doing), now both defaultLocale and defaultULocale are volatile to prevent CPU caching from leading to wrong results.

Tests: I performed some manual tests and the code still behaves the same it's just that now in an environment with 1 CPU with ~6 threads it finishes 2x as fast.

[CLAassistant]

All committers have signed the CLA.

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[richgillam]

Can you please sign the CLA so we can look at this?

[Diego1149]

Hi Rich, thanks for the reminder, this slipped my mind, I've signed the CLA already, so it should be possible for you to look at the contents of this PR.

[richgillam]

I'm a little uncomfortable giving a ship-it here because I'm not longer familiar enough with either Java or the internals of ULocale to be sure I know what's going on. That said, all of this looks pretty reasonable to me. But it'd be nice to have a second pair of eyes on this (@markusicu ?).

[markusicu]

@yumaoka and maybe @macchiati could you please also take a look?

[markusicu]

PS: Consider separate pull requests for the changes in the two classes.

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[markusicu]

I suggest you don't amend/squash right away, so that it's easier to track comments vs. changes. Ignore the one failing check about multiple commits -- we can squash later.

[markusicu]

changes lgtm tnx
I will start the CI checks

looks like good changes now; plan to approve when CI is happy modulo squashing

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[Diego1149]

changes lgtm tnx I will start the CI checks

looks like good changes now; plan to approve when CI is happy modulo squashing

I wish had seen that cause I just squashed it :/

[Diego1149]

Adding my results from my own tests, they still pass as expected:

Test code looks something like this (In Kotlin):

val executor = Executors.newFixedThreadPool(CONCURRENT_FLOWS)
val list: MutableList<Deferred<Long>> = mutableListOf()
for (i in 1..CONCURRENT_FLOWS) {
     list.add(async(executor.asCoroutineDispatcher()) { 
       for (i in 1..NUM_ITERATIONS) {
          // Assert that output of this is correct.
          someChromeOsFunction(INPUT_STRING + i)
        }
     })
}
list.awaitAll()

CONCURRENT_FLOWS=10000
NUM_ITERATIONS=10000
INPUT_STRING="some_input"

I can't append the someChromeOsFunction for obvious reasons, although the code looks something like this:

    BreakIterator breakIterator = BreakIterator.getCharacterInstance();
    breakIterator.setText(input);
    while (breakIterator.current() != BreakIterator.DONE) {
      doSomething(someVariables, breakIterator);
    }

With Optimization:
Took 23258 milliseconds.
Took 22634 milliseconds.
Took 23914 milliseconds.

Without Optimization:
Took 71486 milliseconds.
Took 70137 milliseconds.
Took 75051 milliseconds.

So it's ~3x as fast, although I used 10x the number of virtual threads compared with last time, still same amount of physical threads, so result should be pretty much the same, most of the comments in the cl shouldn't affect perf, but rather were around edge cases in concurrency, so I expect results to stay very similar.