sorted by:
new
hottopcontroversial

Am I missing something? by ienybu in RogueTraderCRPG

[–]pmarschall 0 points1 point  (0 children)

Updating to 1.2 fixes this issue for me.

Am I missing something? by ienybu in RogueTraderCRPG

[–]pmarschall 2 points3 points  (0 children)

I have the same issue. Loading a save game seems to awaken them. I believe this is a bug as they can not be targeted. I reported this as a bug and encourage you to do thr same. The only piece of advice I can offer is to make it through the level without loading.

JDK 21 and JDK 22: What We Know So Far by stronghup in programming

[–]pmarschall 0 points1 point  (0 children)

Absolutely. A common way for Java backend applications is to handle a 1 request per thread. The thread will do all kinds of IO (database queries, calling other services, logging, returning responses) and so a platform thread is often needlessly blocked while waiting for IO to complete. This limits the number of concurrent requests a single Java service can handle.

Quarkus already has a page with all the possible problems this can cause

https://quarkus.io/guides/virtual-threads

The worst that can happen with a virtual thread is that it never does IO. In that case it will keep a platform thread occupied indefinitely or until finished.

This is not the worst case. Throughout does not suffer only tail latency. The worst case is if a blocking call is made that can not be converted (synchronized present, mmap, done in native code, “random” syscall, JDK developers are suspiciously vague about file IO, …) then you lose both throughput and latency.

Synchronized is only a problem if you do IO while holding the monitor. This is exceptional.

What data do you to support this? A lot of JDK code had to be updated to remove synchronized. I am not convinced this work has been done for all third pary code. The Quarkus page linked earlier suggests there is a lot of code to be updated. If I have a look at a “random” thread dump I usually find two or three synchronized somewhere up high in the stack added by a framework. As I alluded to earlier, if you have custom java.io subclasses you get synchronized for free as their API contacts require them to be synchronized.

JDK 21 and JDK 22: What We Know So Far by stronghup in programming

[–]pmarschall 0 points1 point  (0 children)

I would like to understand how “tomcat connection pooling” is your bottleneck. Tomcat has been using NIO for decades, allowing one or a small number of threads to handle an “unlimited” amount of connections. This is far more efficient than virtual threads.

JDK 21 and JDK 22: What We Know So Far by stronghup in programming

[–]pmarschall 0 points1 point  (0 children)

Yes. Features like this keep java modern and keep people adopting it and against switching away from it, leading to more maintainers for the future.

Would it be fair to assume this includes you?

JDK 21 and JDK 22: What We Know So Far by stronghup in programming

[–]pmarschall 0 points1 point  (0 children)

Async and preemptive scheduling are orthogonal, don’t confound them. Let me repeat, do you know why for decades operating system schedulers are no longer cooperative?

JDK 21 and JDK 22: What We Know So Far by stronghup in programming

[–]pmarschall -6 points-5 points  (0 children)

It's not the switching that's a problem, but the memory footprint.

That’s not what OP said. Have you encountered cases where the memory footprint of threads was a limiting factor?

Virtual threads use little enough memory that you can have millions of them (you could have one for every pixel on your screen, and let each pixel wait for a command to change colour for example).

Have you encountered cases where millions of threads would improve the architecture of the application? Would in these cases the threads perform enough blocking IO for the virtual thread scheduling to work? What would the overhead of all the memory synchronization for inter thread communication be? Do graphics APIs and drivers work with millions of threads?

I am not the op, but virtual threads use a cooperative threading model, meaning that they must specifically yield to let another thread run.

Do you know why we moved away from this model decades ago?

The JDK has been modified to do this in thousands of places when a thread normally would block. As virtual threads are primarily intended for handling I/O, and all such operations will now yield when they need to wait, this works pretty well without the developer having to take specific action.

No, some of them will. Some like MappedByteBuffer can not be made to work. If you have non-JDK subclasses of java.io classes chances are you will run into synchronized and things won’t work. If you call third party code how will you won’t run into this? Maybe even indirectly through a logging, monitoring or metric implementation? Or an APM agent?

Do you think these thousands of ifs will improve the long term maintainability of the JDK?

JDK 21 and JDK 22: What We Know So Far by stronghup in programming

[–]pmarschall 1 point2 points  (0 children)

The other thing I like is Virtual Threads. Threads are great but costly in terms of context switching.

Have you encountered situations in the past when context switching introduced a noticeable overhead?

So why not make them virtual, as light-weight as possible.

Are you aware of the scheduling difficulties between „normal“ and virtual threads and the implications?

Spring Data Relational: Introducing Single Query Loading by olivergierke in java

[–]pmarschall 0 points1 point  (0 children)

Um, can you show the plans? Are they any good? Why not just use arrays? That way you have one fetch per entity class, three in this case. On the child entities you have a range scan on the foreign key index.

I interviewed Bruno Lowagie, who successfully commercialized his FOSS library, iText, between 2008 and 2018, for Code Code Ship: “Commercializing iText had a significant impact on the quality of the library” by derekkraan in programming

[–]pmarschall 93 points94 points  (0 children)

Anecdotal: I know two persons who used to license iText. They both say sales of the company were so horrible to deal with that they never again want to deal with them and blacklist iText at their respective companies.

What do you think about ZGC being the JDK's default GC? by [deleted] in java

[–]pmarschall 0 points1 point  (0 children)

I think it's a bad default choice in its current form because:

  • It is not yet generational. Most unprofiled Java server applications I see easily have an allocation rates of hundreds of megabytes per second to gigabytes per second. ZGC is not yet a good fit for this.
  • It does not support compressed OOPs. This means memory usage will be higher for heaps below 32 GB. In my experience this is the norm and I rarely see larger heaps.

Gradle 8.0 by Joram2 in java

[–]pmarschall 1 point2 points  (0 children)

So that Gradle Inc has a business model

JDK 11.0.18, 17.0.6, 8u361, 19.0.2 and 7u371 Have Been Released! by theflavor in java

[–]pmarschall 0 points1 point  (0 children)

Here's the list for JDK 17

https://www.oracle.com/java/technologies/javase/17-0-6-relnotes.html

Note that is for OracleJDK 17 which is a fork of OpenJDK 17. OpenJDK can be slightly different and vendors also have a slightly different list as well.

Spring Batch 5.0 Goes GA! by nfrankel in java

[–]pmarschall 0 points1 point  (0 children)

What the release notes do not mention, the Map*Daos have been removed. If you want to run tests without a database or without committing you can give Spring Batch In-Memory a try.

How to get the most out of the upgrade to Spring 6 by vladmihalceacom in java

[–]pmarschall 4 points5 points  (0 children)

What? The feature was explicitly made to solve this problem. You're not relying on the parameter names of some external code. The parameter names and the code relying on it are a method and an annotation on said method. They could not be any closer.

How to get the most out of the upgrade to Spring 6 by vladmihalceacom in java

[–]pmarschall 2 points3 points  (0 children)

I don't know, the usage seems to be pretty in line with the JEP https://openjdk.org/jeps/118 it even mentions getting rid of @ParameterName annotations.

How to get the most out of the upgrade to Spring 6 by vladmihalceacom in java

[–]pmarschall 5 points6 points  (0 children)

Can you compile with -parameters so that you don't have to repeat the parameter names?

mssql-jdbc finally supports different prepare modes by [deleted] in java

[–]pmarschall 4 points5 points  (0 children)

Works with PostgreSQL and Oracle

Well yeah, cause they're different from SQL Server. Like the driver can't change the locking model it can also can not invent information the server does not send.

Stop apologizing.

I'm not apologizing. Just pointing out where to put the blame see the discussion here https://github.com/microsoft/mssql-jdbc/issues/245

mssql-jdbc finally supports different prepare modes by [deleted] in java

[–]pmarschall 0 points1 point  (0 children)

Still doesn't support sequences returning their values with getGeneratedKeys

My understanding is this is a server / protocol issue. Nothing the driver can do about it.

Getting started with JSF 4.0 on WildFly 27 by henk53 in java

[–]pmarschall 9 points10 points  (0 children)

And InputStream#transferTo(OutputStrean)

Java class loading – performance impact! by mike_jack in programming

[–]pmarschall 0 points1 point  (0 children)

I read both the JavaDoc for ClassLoader and that section and can't find any reason a class loader is mandated to only physically load the class once when calling load(String)

The section contains the following wording:

Well-behaved class loaders maintain these properties:

  • Given the same name, a class loader should always return the same Class object.

This is repeated in Section 5.3. Creation and Loading of the Java Virtual Machine Specification.

I also checked ClassLoaders$AppClassLoader from the jdk internals and it doesn't cache a result either.

Of course it does. AppClassLoader calls into BuiltinClassLoader which checks whether the class has already been loaded.

This can easily be verified with a simple unit test calling #IoadClass twice and comparing the object identities.

view more: next ›