On 2022-03-11 18:18, Thomas Stüfe wrote:
As Dalibor wrote, I would not expect too many performance surprises.
Actually, I would seriously assume that any other compiler than VS on
Windows will give much worse results. The VS compiler is
battle-hardened. Gcc and clang is only used by a very small enthusiastic
hobbyist minority. There is no reason to believe it will be even close
to optimized. Most likely there will be strange bugs with anything that
requires OS interaction (like dll loading and whatsnot), even if the
basic code generation part of the compiler should be identical for all
OSes running on the same CPU.
That said, a more pragmatic approach may be to create a shim layer for
visual studio compiler and linker, e.g. a fake "cl.exe" and "link.exe"
that translate VC++ options and paths to whatever toolchain you like.
That way you don't have to touch the OpenJDK make at all. I know it
works in principle since I have such a thing in the past, albeit for a
different product and a different target toolchain.
But there is oh so much to "convert" in that case. Just try grepping for
"pragma" in hotspot, for a start. :)
I seriously do not believe this approach would be any ounce simpler, at
least not for the JDK.
I did actually start to try to get a "hybrid" mode working, where the
Visual Studio CL compiler would be run using wine on linux. (This was
previously not allowed by MS licence, but they changed it some years
ago.) That'd had allowed for linux users to cross-compile to Windows,
and make a quick check that you did not break the build. But even this
small step -- keeping the Windows compiler, but running in a linux
environment -- turned out to be so full of tricky details that I gave up
on it.
/Magnus
I would not be surprised if such a thing exists already. It seems such
an obvious idea.
Cheers, Thomas
On Fri, Mar 11, 2022 at 2:35 PM Julian Waters
<tanksherma...@gmail.com> wrote:
Darn, seems like it'll be much harder than I expected. Since multiple
toolchains are supported for macOS and Linux, I assumed a slight patch
would help get it to work on Windows. Looking through the stuff in
make
though, it appears a lot of the build system implicitly expects the
compiler for Windows to always be Visual C++, which doesn't really
help
that much (Though the fact that we can exclude many versions of
gcc, such
as Cygwin's and old MinGW binaries helps a lot). The build process
for the
newer Windows ports of gcc are surprisingly similar to Visual C++
though
(Eg rc can be swapped out for windres) so this might hopefully be
something
I can try exploring in the future (Gonna look a bit harder at make and
write what I can find back to this mailing list in the meantime).
It'd be
interesting if benchmarks of the JVM compiled with different
compilers on
Windows can be compared side by side on the off chance this becomes a
reality though
best regards,
Julian
On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2022-03-11 12:55, Julian Waters wrote:
>
> > Hi all,
> >
> > How feasible would it be/much effort would it require to support
> compiling
> > with alternate toolchains on Windows besides Visual C++ (like
the Windows
> > ports of clang and gcc) if we restrict the allowed toolchains
to only
> those
> > that link against the ucrt? (Toolchains linking against the
dated msvcrt
> > would present too many issues to work with)
>
> That'd be a huge undertaking. And any such patch would only be
accepted
> into the code base if the organization behinded appeared
trustworthy in
> their long-term commitment to keeping it working.
>
> /Magnus
>
>
>
