Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Useless MethodHandles code in server entrypoint (& other random comments on the code) #1

Open
solonovamax opened this issue Mar 9, 2025 · 3 comments

Comments

@solonovamax
Copy link

Why is there some seemingly useless MethodHandles code in the server entrypoint?

none of it seems to do anything, so why is it there?

@solonovamax
Copy link
Author

there also seems to be some weird stuff like DirectionBool, which is just empty

@solonovamax
Copy link
Author

solonovamax commented Mar 9, 2025

also in Sampler you are doing some funny reflection stuff to avoid hotspot optimizing away the field assignment (based on the comment)

afaik if you mark the field as volatile, that should prevent it from optimizing it out by essentially saying "other threads may do funny stuff and mess around with this", though I could be wrong on that. you'd have to try it out. I checked with some people who know slightly more about the jvm than I do, and yeah, volatile is what you want (I was like 85% sure but wanted to double check)

@solonovamax solonovamax changed the title Useless MethodHandles code in server entrypoint Useless MethodHandles code in server entrypoint (& other random comments on the code) Mar 9, 2025
@RubixTheSlime
Copy link
Owner

a lot of the dead weight code is simply there because it's still really early in development so i haven't bothered to clean anything up, unless it affects the profiler's performance. like there's one part where it calculates several types of averages and then does nothing with any of them. with the MethodHandles i was at one point experimenting with some sort of primer part to account for the first of any given thing in a tick taking longer to process (at the time i had only noticed that the first tile tick, entity, tile entity, etc in general was slower, not necessarily of each individual type of entity), and just made a centralized non-optimizable no-op as part of the code before realizing that the issue was more complex than i thought.

thank you for the volatile tip! i normally don't work with threads so i completely forgot about that and just googled "how to make code not optimize out"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants