Code in hotspot/make/windows/makefiles/defs.make to detect build machine
architecture could use some simplification

It uses a grep on the PROCESS_IDENTIFIER environment variable.
For 64 bit it historically looked like this:
ifneq ($(shell $(ECHO) $(PROCESSOR_IDENTIFIER) | $(GREP) AMD64),)

The problem with this is that this doesn't recognise Intel chips.
So another block was added for that
ifneq ($(shell $(ECHO) $(PROCESSOR_IDENTIFIER) | $(GREP) EM64T),)

Then it was discovered that on later OSes such as Vista, Windows 7 etc
the reported string is "Intel64".
So this was changed to
ifneq ($(shell $(ECHO) $(PROCESSOR_IDENTIFIER) | $(GREP) "EM64T\|Intel64"),)

Now it is found that this works for cygwin grep but not mks grep.
So the low risk answer has been to create yet another new block.

It would be better to have one block detect all three strings.

The suggestion from John Coomes is :
=====================
The $(filter) function may allow you to use a single test, e.g.,

ifneq ($(filter AMD64 EM64T Intel64,$(PROCESSOR_IDENTIFIER)),)
...
endif

This works as long as AMD64, EM64T or Intel64 appear as
space-separated words in PROCESSOR_IDENTIFIER. The key is
space-separated; e.g., 'AMD64 (tm)' will be matched by the above, but
'AMD64(tm)' will not be matched.

I don't know the expected contents of $(PROCESSOR_IDENTIFIER).
=================================

To implement this will require verification that this
* works as advertised with all expected values of PROCESSOR_IDENTIFIER
* works on mks and cygwin builds
* works for all the values (AMD64, Intel64, EM64T), which probably
  requires having several installs.

So filing this as an RFE for later handling.

However it was also noted in 6951582 that PROCESSOR_IDENTIFIER
itself is not necessarily the best thing to test.
Newer versions cygwin's ssh environment may remove this variable, and jprt builds
may not work if they use ss, which I think they may do.

So something else may be needed.