ScopedValue.runWhere not returning scope

[Robert Engels]

I’m sorry, I am not following your reasoning.

If they are not redesigning their applications to use VT threads, there is no reason to change anything. The number of threads will stay the same, and the difference in performance between TL and SV won’t have any significance.

If they redesign their applications to use VT - then there could potentially be millions of threads/requests - all unique - so it needs a different sort of tracing methodology anyway - regardless of whether scoped values perform better than thread locals - so they will need a different tracing library/api.

Just presenting this data is a challenge. I suggest you look at Go and its tracing facilities. It is a problem there as well for these situations. It’s not a trivial problem to solve (visualizing/using tracing data from potentially millions of active threads). Same goes with debugging. Check out github.com/robaho/goanalyzer <http://github.com/robaho/goanalyzer> and the linked issues.

As to the specific question as to whether SV will outperform TL, I gather the answer is “it depends” (and Ron/Alan are certainly the authoritative persons). But reading the JEP, https://openjdk.org/jeps/446 <https://openjdk.org/jeps/446> it seems clear that the performance gains are from immutability (easier sharing, lower memory footprint vs inherited TL) and the aspects related to having potentially millions of them - which brings me back to my original point.

From the JEP... "In general, we advise migration to scoped values when the purpose of a thread-local variable aligns with the goal of a scoped value: one-way transmission of unchanging data.” - which doesn’t appear to align with a tracing library, but it probably depends on how it used/implemented.


> On Jun 10, 2024, at 9:48 AM, Marcin Grzejszczak <marcin.grzejszczak at gmail.com> wrote:
> 
> OK, but can we confirm some assumptions first? 
> 
> Do I understand correctly that ScopedValues will be significantly faster than Thread Locals? If that's the case just by returning a Scope object instead of expecting a lambda all the tracing libraries and all instrumentations that are out there will not need a major redesign. I think that it's worthwhile to consider such an option in that scenario.
> 
> Pozdrawiam / Best regards,
> Marcin Grzejszczak
> 
> https://marcin.grzejszczak.pl <https://marcin.grzejszczak.pl/>
> https://toomuchcoding.com <https://toomuchcoding.com/>
> 
> pt., 7 cze 2024 o 15:39 robert engels <robaho at icloud.com <mailto:robaho at icloud.com>> napisał(a):
> My understanding is that the only performance downside to TL is due to the sheer number of threads possible vs a platform thread solution. Most likely existing tracing solutions are not designed to support this anyway - it would orders of magnitude more tracing information to track and disseminate. If the tracing solution already supports high volume async requests it’s doubtful it uses TL based solutions as the would be needless overhead. 
> 
> If you don’t redesign the software to take advantage of VT then it won’t matter.  
> 
> I expect someone will design a VT optimized tracing solution though. I also expect the TL based solutions will still work though - maybe not optimally. 
> 
>> On Jun 7, 2024, at 10:15 AM, Marcin Grzejszczak <marcin.grzejszczak at gmail.com <mailto:marcin.grzejszczak at gmail.com>> wrote:
>> 
>> 
>> > I am struggling to understand the concern. If you have a TL based solution just stick with it. If the people are changing their code to use VT then they are probably redesigning anyway - e.g. removing any async. 
>> 
>> Let me quote one of my previous replies: "I mean if there's no distinction in terms of performance between Scoped Values and Thread Locals then we should just need to ensure that there's an interop between Thread Locals and Scoped Values and current implementations could stay on Thread Locals. But I thought that the very idea is to use Scoped Values preferably with Virtual Threads to have best performance in comparison to using Thread Locals. Maybe I made a mistake in this assumption?". 
>> 
>> > If they are redesigning they can use an interceptor based solution that is designed for scoped variables. 
>> 
>> That would require a lot of libraries to redesign their API. I'm not saying this is a bad thing but that might be a lot of work on many different projects. Also some libraries will migrate, some won't so there needs to be an interop between TL and SV.
>> 
>> Pozdrawiam / Best regards,
>> Marcin Grzejszczak
>> 
>> https://marcin.grzejszczak.pl <https://marcin.grzejszczak.pl/>
>> https://toomuchcoding.com <https://toomuchcoding.com/>
>> 
>> pt., 7 cze 2024 o 15:11 robert engels <robaho at icloud.com <mailto:robaho at icloud.com>> napisał(a):
>> I am struggling to understand the concern. If you have a TL based solution just stick with it. If the people are changing their code to use VT then they are probably redesigning anyway - e.g. removing any async. 
>> 
>> If they are redesigning they can use an interceptor based solution that is designed for scoped variables. 
>> 
>>> On Jun 7, 2024, at 10:03 AM, Marcin Grzejszczak <marcin.grzejszczak at gmail.com <mailto:marcin.grzejszczak at gmail.com>> wrote:
>>> 
>>> 
>>> > In AspectJ`s terms, interceptors such as these are equivalent to before and after advice.
>>> 
>>> Correct.
>>> 
>>> > To enable something like a ScopedValueInterceptor, it seems to me sufficient to extend this scheme to include around advice. The handler of AroundInterceptors would pass a proceed object to the around advice. ScopedValueAroundInterceptor would do whatever it wants to do, call scopedValue.runWhere, then call proceed inside that scope.
>>> 
>>> Agreed. For this scenario preferably one could use the around advice. That's in the case of an ideal solution where all projects are green fields. But we're not in such a state.
>>> 
>>> > If a design like this was deemed overkill before, perhaps its time has arrived.
>>> 
>>> I wonder if the solution that the library maintainers should be required to migrate to a new design is the proper one. I've only listed 8 projects that Micrometer Observation instruments but I'm pretty sure that there are more. I wonder if such an ask to redesign the API wouldn't be an overkill?
>>> 
>>> Pozdrawiam / Best regards,
>>> Marcin Grzejszczak
>>> 
>>> https://marcin.grzejszczak.pl <https://marcin.grzejszczak.pl/>
>>> https://toomuchcoding.com <https://toomuchcoding.com/>
>>> 
>>> pt., 7 cze 2024 o 14:52 Pedro Lamarão <pedro.lamarao at prodist.com.br <mailto:pedro.lamarao at prodist.com.br>> napisał(a):
>>> Em sex., 7 de jun. de 2024 às 10:05, Marcin Grzejszczak <marcin.grzejszczak at gmail.com <mailto:marcin.grzejszczak at gmail.com>> escreveu:
>>>  
>>> > Can you explain that a little more? Why can't isolated functionality be added without separate before and after logic?
>>> 
>>> I mentioned that above but I'll try to rephrase it. There are already solutions such as Apache CXF [1], Apache Commons for Http client [2], Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] that work with such interceptors. All that code would have to be rewritten. I'm not saying that this is not feasible but let's be realistic. Also if all of those libraries wouldn't rewrite their code then distributed tracing would be broken. If one service is not working then instead of one correlation you will get two or more.
>>> 
>>> In AspectJ`s terms, interceptors such as these are equivalent to before and after advice.
>>> To enable something like a ScopedValueInterceptor, it seems to me sufficient to extend this scheme to include around advices.
>>> The handler of AroundInterceptors would pass a proceed object to the around advice.
>>> ScopedValueAroundInterceptor would do whatever it wants to do, call scopedValue.runWhere, then call proceed inside that scope.
>>> If a design like this was deemed overkill before, perhaps its time has arrived.
>>> 
>>> -- 
>>> Pedro Lamarão

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240610/bd764357/attachment-0001.htm>