Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JVM is not that heavy

opensourcery.co.za

Post reply on HN
Print view View original

331–340 of 373 posts

Re: The JVM is not that heavy

#331

Post by adrianN »

geocar wrote: post #320
adrianN wrote: post #288

Earlier quoted context omitted.

Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching. You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application.

> Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching. Cache fills optimize for linear scans, and have nothing to do with eviction. > You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application. What ass…

If your assumption that a 10MB JVM kills the cache were true, then the alioth benchmarks you have posted wouldn't show a speed difference of ~3. I suggest you learn a bit more about how CPUs work and what benchmarks mean before posting bold claims.

Re: The JVM is not that heavy

#332

Post by geodel »

simonh wrote: post #299
geodel wrote: post #297

Earlier quoted context omitted.

> I feel that if Android were being developed today, they'd almost certainly take .NET Core as the runtime. If it were to develop today as against raising against time(Apple) then Google would have written their own runtime and everything.

But then when Android was initially developed and acquired by Google Apple wasn't in the phone business at all, so the base architecture was already laid down long before the race started.

Apple was getting in phone business at that time. Original Android was nothing like Android user saw when it was released on phone. Google had advanced knowledge about Apple plans as Eric Schmidt was on Apple board at that time.

Re: The JVM is not that heavy

#333

Post by pjmlp »

geodel wrote: post #300
pjmlp wrote: post #242

Earlier quoted context omitted.

With users that use commercial features without paying for them. It is quite easy to know which features those are when they require a flag named -XX:+UnlockCommercialFeatures , you just don't use them by mistake.

Oracle gives free license to use commercial features in development[1] in section B. It is very easy to some script for JVM startup parameters and get that script deployed in production by mistake. 1. http://www.oracle.com/technetwork/java/javase/terms/license/...

Quite right, but unless I am too cynical I doubt those deployments were actually done by mistake, when I relate how many companies try to "alleviate" their costs.

Re: The JVM is not that heavy

#334

Post by geodel »

hrjet wrote: post #314
mike_hearn wrote: post #262

Earlier quoted context omitted.

Are you sure? I've written small HTTP servers in Java that can happily run with a heap of 30-50mb or less. Runtime overheads add some on top of that, but not much. I think the perception of Java suffers a lot because it will consume all the RAM on your machine by default if you let it (but not immediately). It's a very poor default because even though there are technical arguments for doing that (goes faster), they a…

> I've written small HTTP servers in Java that can happily run with a heap of 30-50mb or less. Runtime overheads add some on top of that, but not much. I second that. I have deployed a medium traffic web-server written in Scala backed by a postgresql DB on 128MB VPS, back in 2009! > I think the perception of Java suffers a lot because it will consume all the RAM on your machine by default if you let it (but not immed…

Must be Java 6 in 2009. Java memory usage increased with new releases to make it perform better. For medium traffic site it would have worked fine because GC would have ample time to clean unused objects.

Re: The JVM is not that heavy

#335

Post by snuxoll »

lmm wrote: post #328
snuxoll wrote: post #324

Earlier quoted context omitted.

> Is that one cross-platform file? No, and neither is a Go or Rust binary, next question. > Is it even portable across different linux distributions? Nothing preventing me from taking an extra 10 minutes to modify the spec to support SUSE, Fedora support usually comes for free if you support el7. You like Debian derivatives? Let me toss a debian/ directory in there, that'll only take a couple minutes too. Added benef…

> No, and neither is a Go or Rust binary Sure, I'm comparing with the JVM per the article. > Nothing preventing me from taking an extra 10 minutes Indeed, but 10 minutes here, 10 minutes there, it all adds up. > Different libraries? Do you mean different VERSIONS of libraries? No, I mean some native libraries not installed. Does your package declare what packages it depends on? How do you handle different distributio…

> Sure, I'm comparing with the JVM per the article.

Fair enough, though I still use RPM's to deploy Java (Spring Boot even!) applications.

> Indeed, but 10 minutes here, 10 minutes there, it all adds up.

In the grand scheme of software development updating the .spec file or debian control file is peanuts.

> No, I mean some native libraries not installed. Does your package declare what packages it depends on? How do you handle different distributions using different package names for the same libraries.

In the case of RPM based distributions, some conditional macro's in the .spec file that swap out Requires/BuildRequires statements based on the distribution the package is being built for. I never bother with SUSE personally, but there are differences between EL7 and Fedora that I have to keep track of.

> But if there's no clear standard everyone ends up doing it slightly differently, and then every project you pick up you have to understand how they've set things up.

.spec files are more standard than most build tooling. The only thing that complicates them is projects without an adequate build system in the first place, everything else is minor style differences based on who wrote the spec.

Everything has been done before, unless you are using some extremely new or extremely niche language or build tool chances are your spec file will be easy to figure out, since any and all complexity is explicitly linked to how easy it is to build and install your software in the first place.

Re: The JVM is not that heavy

#336

Post by klodolph »

martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

I wonder how much of this is due to a couple differences: in Go you can embed structures in others instead of using a pointer, strings are UTF-8, and arrays (slices) are resizeable by default.

(I'm sure a chunk of the difference is due to a better understanding of the program during rewrites.)

Re: The JVM is not that heavy

#337

Post by geodel »

kodablah wrote: post #125
martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

As another commenter mentioned, I think this is much more the programmer and less the language. Sure, the language may recommend certain approaches which carry across teams differently, but it still often comes down to the app, not the language. I implemented a rudimentary Java AOT targetting Go and the trimmed-down stdlib grew so big Go took hours compiling it (granted some of that is how I approached OOP and what n…

> I implemented a rudimentary Java AOT targetting Go and the trimmed-down stdlib grew so big Go took hours compiling it

Have you reported to Go devs? Sounds interested use case.

Re: The JVM is not that heavy

#338

Post by ManFromUranus »

towndrunk wrote: post #306
nikcub wrote: post #261

Microsoft seem to have learned a lot from Java in designing their new .NET Core CLR. It has gotten almost everything right: * a small and fast CLR (JVM) * a class library that defaults to almost nothing but primitive classes * proper and standardized version, platform and package management (NuGet) * open source and MIT license[0] * a patent promise[1] * arguably the best dev IDE available (Visual Studio) and one of…

> they left out, for now, attempting the hard ugly stuff like x-platform GUI What is the status of this? Will MS be bringing WPF (XAML) to all platforms?

IMO Microsoft will never bring WPF to any other platform but windows. Core CLR (and web GUIs) are what will be available on other platforms. I think that WPF will always remain a windows thing. For that matter WPF is not even getting developed much on Windows and is largely left as it is in favor of putting their effort into web technologies and CoreCLR

Re: The JVM is not that heavy

#339

Post by yxhuvud »

hannob wrote: post #100

I must admit my experience is a few years old, but one thing that the whole text doesn't mention and that has contributed a lot to the negativity I feel towards the java ecosystem: It seemed not well integrated in the Linux ecosystem. What do I mean? I often experienced that Java dependencies were not readily available in Linux distros. Packaging Java stuff was - weird and complicated, not sure how to better phrase i…

You can rely on ruby packages being properly packaged? Ahahahaahaha. They package what is necessary for the end user apps (like redmine) that they support, and a very bare minimum of other gems. Then you are stuck trying to match their release of updated versions with the ones you use. That seldom matches the update speed you will want, for neither ruby versions nor gem versions.

Re: The JVM is not that heavy

#340

Post by tynpeddler »

kazagistar wrote: post #317
Zach_the_Lizard wrote: post #289

Earlier quoted context omitted.

And at work, we're now rewriting all those NodeJS services in Go or Java. We hired some Node maintainer(s) a long time ago, rumor has it, who got us on the Node train.

How do you do async in java? While it does have CompletableFutures now, none of the libraries (specifically databard drivers) seem to support it, so I always end up with a blocked thread per request.

Java has had non-blocking IO for some time. https://en.wikipedia.org/wiki/Non-blocking_I/O_(Java)

Unfortunately it seems difficult to use (to me at least), but frameworks like netty are build on top of it to provide incredible performance.

However, the fact that Java provides real threading means that a blocking io is not a performance problem if you use the correct patterns.

Post reply on HN