lj_jit.h: Increase HOTCOUNT_MAX and expand HotPenalty.val

Increase HOTCOUNT_MAX so that the JIT will make more attempts to trace
a bytecode before it blacklists. Expand the HotPenalty.val from 16-bit
to 32-bit to accommodate the larger value.

HOTCOUNT_MAX is increased from 60,000 to 6,000,000. This is a 100x
increase but the effect should be much smaller, log2(100) times,
because the penalty value is increased exponentially.

I don't entirely understand the existing design of the hotcount penalty:
- Why initialize HOTCOUNT_MIN at 36*2?
- Why increase the penalty exponentially instead of incrementally?
- Why add random entropy to the increases?

So I only hope that this patch doesn't break any important properties.

src/lj_jit.h

@@ -220,13 +220,13 @@ static LJ_AINLINE MSize snap_nextofs(GCtrace *T, SnapShot *snap)
 /* Round-robin penalty cache for bytecodes leading to aborted traces. */
 typedef struct HotPenalty {
   MRef pc;		/* Starting bytecode PC. */
-  uint16_t val;		/* Penalty value, i.e. hotcount start. */
+  uint32_t val;		/* Penalty value, i.e. hotcount start. */
   uint16_t reason;	/* Abort reason (really TraceErr). */
 } HotPenalty;
 
 #define PENALTY_SLOTS	64	/* Penalty cache slot. Must be a power of 2. */
 #define PENALTY_MIN	(36*2)	/* Minimum penalty value. */
-#define PENALTY_MAX	60000	/* Maximum penalty value. */
+#define PENALTY_MAX	6000000	/* Maximum penalty value. */
 #define PENALTY_RNDBITS	4	/* # of random bits to add to penalty value. */
 
 /* Round-robin backpropagation cache for narrowing conversions. */

src/lj_trace.c

@@ -327,7 +327,7 @@ static void penalty_pc(jit_State *J, GCproto *pt, BCIns *pc, TraceError e)
   J->penaltyslot = (J->penaltyslot + 1) & (PENALTY_SLOTS-1);
   setmref(J->penalty[i].pc, pc);
 setpenalty:
-  J->penalty[i].val = (uint16_t)val;
+  J->penalty[i].val = val;
   J->penalty[i].reason = e;
   hotcount_set(J2GG(J), pc+1, val);
 }