<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’m sorry, I am not following your reasoning.<div class=""><br class=""></div><div class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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 <a href="http://github.com/robaho/goanalyzer" class="">github.com/robaho/goanalyzer</a> and the linked issues.</div><div class=""><br class=""></div><div class="">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, <a href="https://openjdk.org/jeps/446" class="">https://openjdk.org/jeps/446</a> 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.</div><div class=""><br class=""></div><div class="">From the JEP... "<b class="">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.</b>” - which doesn’t appear to align with a tracing library, but it probably depends on how it used/implemented.</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 10, 2024, at 9:48 AM, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com" class="">marcin.grzejszczak@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">OK, but can we confirm some assumptions first? </div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class=""><div class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">Pozdrawiam / Best regards,</div><div class="">Marcin Grzejszczak</div><div class=""><br class=""><div class=""><a href="https://marcin.grzejszczak.pl/" target="_blank" class="">https://marcin.grzejszczak.pl</a></div><div class=""><a href="https://toomuchcoding.com/" target="_blank" class="">https://toomuchcoding.com</a></div></div></div></div></div></div></div><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pt., 7 cze 2024 o 15:39 robert engels <<a href="mailto:robaho@icloud.com" class="">robaho@icloud.com</a>> napisał(a):<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div dir="ltr" class=""></div><div dir="ltr" class="">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. </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">If you don’t redesign the software to take advantage of VT then it won’t matter. </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">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. </div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Jun 7, 2024, at 10:15 AM, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com" target="_blank" class="">marcin.grzejszczak@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">> 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. <br class=""></div><div class=""><br class=""></div><div class="">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?". <br class=""></div><div class=""><br class=""></div><div class="">> If they are redesigning they can use an interceptor based solution that is designed for scoped variables. <br class=""></div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">Pozdrawiam / Best regards,</div><div class="">Marcin Grzejszczak</div><div class=""><br class=""><div class=""><a href="https://marcin.grzejszczak.pl/" target="_blank" class="">https://marcin.grzejszczak.pl</a></div><div class=""><a href="https://toomuchcoding.com/" target="_blank" class="">https://toomuchcoding.com</a></div></div></div></div></div></div></div><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pt., 7 cze 2024 o 15:11 robert engels <<a href="mailto:robaho@icloud.com" target="_blank" class="">robaho@icloud.com</a>> napisał(a):<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div dir="ltr" class=""></div><div dir="ltr" class="">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. </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">If they are redesigning they can use an interceptor based solution that is designed for scoped variables. </div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Jun 7, 2024, at 10:03 AM, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com" target="_blank" class="">marcin.grzejszczak@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">> In AspectJ`s terms, interceptors such as these are equivalent to before and after advice.</div><div class=""><br class=""></div><div class="">Correct.<br class=""></div><div class=""><br class=""></div><div class="">> 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.</div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">> If a design like this was deemed overkill before, perhaps its time has arrived.<br class=""><br class=""></div><div class="">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?<br class=""></div><div class=""><br class=""></div><div class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">Pozdrawiam / Best regards,</div><div class="">Marcin Grzejszczak</div><div class=""><br class=""><div class=""><a href="https://marcin.grzejszczak.pl/" target="_blank" class="">https://marcin.grzejszczak.pl</a></div><div class=""><a href="https://toomuchcoding.com/" target="_blank" class="">https://toomuchcoding.com</a></div></div></div></div></div></div></div><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pt., 7 cze 2024 o 14:52 Pedro Lamarão <<a href="mailto:pedro.lamarao@prodist.com.br" target="_blank" class="">pedro.lamarao@prodist.com.br</a>> napisał(a):<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class="">Em sex., 7 de jun. de 2024 às 10:05, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com" target="_blank" class="">marcin.grzejszczak@gmail.com</a>> escreveu:<br class=""></div><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">> Can you explain that a little more? Why can't isolated functionality be added without separate before and after logic?<br class=""></div><div class=""><br class=""></div><div class="">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.</div></div></blockquote></div><div class=""><br class=""></div><div class="">In AspectJ`s terms, interceptors such as these are equivalent to before and after advice.</div><div class="">To enable something like a ScopedValueInterceptor, it seems to me sufficient to extend this scheme to include around advices.</div><div class="">The handler of AroundInterceptors would pass a proceed object to the around advice.</div><div class="">ScopedValueAroundInterceptor would do whatever it wants to do, call scopedValue.runWhere, then call proceed inside that scope.</div><div class="">If a design like this was deemed overkill before, perhaps its time has arrived.</div><div class=""><br class=""></div><span class="gmail_signature_prefix">-- </span><br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class="">Pedro Lamarão</div></div></div></div>
</blockquote></div>
</div></blockquote></div></blockquote></div>
</div></blockquote></div></blockquote></div>
</div></blockquote></div><br class=""></div></div></body></html>